Hub에 RL 환경을 환영합니다
요약
Hugging Face Hub에 RL(강화학습) 환경을 공식적으로 지원하여, 데이터셋 레포지토리가 다양한 프레임워크에서 실행 가능한 환경 파일들을 호스팅할 수 있게 되었습니다. 이를 통해 기존의 사일로화된 환경 공유 문제를 해결하고, 사용자들이 어떤 프레임워크와도 쉽게 연동할 수 있도록 합니다.
핵심 포인트
- Hub에 RL Environments 필터가 추가되어 접근성이 높아졌습니다.
- 데이터셋 레포지토리가 다양한 프레임워크를 지원하는 핵심 허브 역할을 수행합니다.
- 환경의 사일로화 문제를 해결하여 호환성을 크게 개선했습니다.
- 사용자는 여러 프레임워크 태그를 통해 환경의 범용성을 확인할 수 있습니다.
환경(environment)은 에이전트에게 과제를 제공하고, 그 행동에 대한 관측값(observations)으로 응답하며, 결과에 점수를 매깁니다. 이렇게 얻은 보상(rewards)은 평가 중 에이전트의 성능을 측정하거나 훈련 중 학습 신호(learning signal)를 제공할 수 있습니다. 이 상호작용 루프(interaction loop)에 대한 소개는 환경 관련 블로그 게시물을 참고하십시오. 환경 내에서 에이전트는 데이터셋으로 표현되는 일련의 과제를 수행하게 됩니다. 따라서 환경은 크게 두 부분, 즉 태스크셋(tasksets)과 런타임(runtimes)으로 나눌 수 있습니다. 이번 릴리스에서는 태스크셋에 중점을 두고 있습니다.

Hub의 RL 환경은 새로운 RL Environments 필터에 표시되는 데이터셋 레포지토리입니다. 이 데이터셋 사용하기 버튼을 누르면 해당 프레임워크에서 실행할 수 있는 명령을 얻게 됩니다. 새로운 레포 유형, 등록소(registry), 또는 가입 절차는 없습니다. 이미 Harbor, Verifiers, 그리고 NVIDIA NeMo Gym에 환경들이 존재합니다.
모든 RL 논문이나 프레임워크는 자신만의 방식으로 환경을 찾습니다. 사용자 지정 허브, 런타임 등록소, 독립적인 태스크 데이터셋, 또는 커스텀 로더가 있는 GitHub 목록 등이 그것입니다. 이는 게시된 많은 환경들이 사일로화(siloed)되어 있다는 것을 의미합니다. 즉, 한 프레임워크를 위해 환경을 게시하면 다른 세 가지 프레임워크의 사용자는 이를 불러올 수 없습니다. 만약 다른 프레임워크나 새로운 논문의 환경으로 훈련하고 싶다면, 직접 포팅(port)해야 합니다.
우리는 이것이 잘못된 형태라고 생각합니다. 환경은 태스크, 테스트, 컨테이너, 그리고 보상 규칙이며, 이는 런타임을 기반으로 하는 데이터입니다. Hub는 이미 데이터를 저장하고, 버전을 관리하며, 게이트를 설정하고, 미리 보여주고, 수백만 명의 사람들에게 제공합니다. 환경을 담기 위해 두 번째 시스템이 필요하지 않습니다. 필요한 것은
데이터셋 레포지토리는 환경 파일들을 호스팅합니다. 이 프레임워크는 로컬 또는 지원되는 클라우드 백엔드에서 이를 실행할 수 있습니다. Hugging Face Jobs를 사용하면 클라우드 워크로드를 실행할 수 있으며, Jobs를 기반으로 구축된 Hugging Face Sandboxes는 대화형 명령어 실행을 제공합니다. 태그는 호환성을 설명하고 로딩 명령어를 생성하며, 태그를 추가한다고 해서 작업(job)이나 샌드박스가 시작되는 것은 아닙니다.
RL 환경 필터. huggingface.co/datasets?other=rl-environment로 이동하세요. rl-environment 태그가 붙은 모든 데이터셋이 어떤 프레임워크와 작동하든 상관없이 그곳에 나타납니다.
프레임워크 태그. 네 가지 환경 프레임워크가 데이터셋 라이브러리로 등록되어 있습니다:
각 프레임워크 태그는 해당 프레임워크의 아이콘을 데이터셋 페이지에 표시하고 이 데이터셋 사용하기(Use this dataset) 섹션에 생성된 코드 스니펫을 추가합니다.
데이터셋은 여러 개의 프레임워크 태그를 가질 수 있습니다. 그것이 핵심입니다. 태그는 호환성을 설명하며, 호환성은 배타적이지 않습니다. 나열된 각 프레임워크는 레포지토리의 파일을 지원해야 하며, 태그를 추가한다고 해서 파일 형식이 변하는 것은 아닙니다.
사용하려는 프레임워크에 대한 예제를 선택하고 아래 명시된 필수 조건들로 별도의 Python 환경에서 실행하세요.
Harbor는 Hub 레포지토리에서 작업 디렉토리를 로드할 수 있습니다. 오라클 에이전트(oracle agent)가 작업의 기준 솔루션(reference solution)을 실행한 다음, 검증기(verifier)가 결과를 채점합니다. 이는 모델을 호출하지 않습니다.
uv tool install --python 3.13 'harbor==0.21.0'
harbor run \
--repo https://huggingface.co/datasets/harborframework/terminal-bench-2.1 \
...
뷰어(viewer)는 작업의 보상, 검증기 출력 및 로그를 보여줍니다. 이는 모델 에이전트를 시도하기 전에 작업을 그리고 그 기준 솔루션을 확인합니다.
The Harbor 통합된 verifiers v1은 Docker와 같은 다양한 런타임에서 동일한 작업 디렉토리를 실행할 수 있습니다. 또한 최소한의 bash harness를 포함하여 다양한 하네스(harness)도 지원합니다.
uvx --python 3.13 --from 'verifiers[harbor]' eval harbor \
--env.taskset.repo https://huggingface.co/datasets/harborframework/terminal-bench-2.1 \
--env.taskset.dataset [email protected] \
...
이 저장소는 전체 Hugging Face Git URL이며, 데이터셋은 해당 저장소의 registry.json에 명시된 이름과 버전입니다. 이 로더는 Harbor의 레지스트리 관례를 사용하므로, 단순한 Hub 저장소 ID로는 두 값을 모두 대체할 수 없습니다.
OpenEnv의 Harbor 통합 기능을 사용하면 OpenCode와 같은 에이전트를 사용하여 동일한 작업 디렉터리를 실행하고, 에이전트의 추적 기록과 함께 검증기(verifier)의 보상(reward)을 반환받을 수 있습니다.
pip install "openenv[harbor]==0.7.0"
openenv harbor rollout \
--llm-url "$LLM_URL" \
...
이 명령어는 데이터셋의 tasks/ 디렉터리를 다운로드하고, Docker에서 하나의 작업을 실행한 후 결과를 작성합니다. 기본 연결은 임시 Gradio 터널을 사용하여 격리된(sandboxed) 에이전트가 OpenEnv의 모델 프록시에 접근할 수 있도록 합니다. 검증기 결과와 모델 호출 횟수를 확인하세요:
import json
from pathlib import Path
result = json.loads(Path("rollout.json").read_text())[0]
...
None 보상은 검증기 보상이 생성되지 않았음을 의미합니다. 실행이 모델 실패로 해석되기 전에 error를 확인하세요. 이 경로는 Harbor 작업 디렉터리를 예상합니다.
NeMo Gym은 평가(evaluation)와 강화학습(RL) 훈련을 지원합니다. 환경은 궤적(trajectories)을 수집하고 보상을 계산하며, 훈련 프레임워크는 모델 가중치(model weights)를 업데이트합니다. 예를 들어, Structured Outputs 데이터셋은 프롬프트와 JSON 스키마를 쌍으로 연결합니다. 이 데이터셋의 검증기는 스키마 준수 여부를 확인하지만, 생성된 콘텐츠가 사실적으로 정확한지는 확인하지 않습니다.
가장 좋은 점은 이것이 모든 주요 프레임워크에서 문제가 있는 작업을 보고하는 한 곳의 저장소와 토론 탭을 제공한다는 것입니다. 따라서 저자가 나쁜 테스트를 수정하면, 다음 풀(pull) 때마다 모든 프레임워크에 수정 사항이 적용됩니다.
데이터셋 카드(dataset card)를 열고 YAML 헤더에 이것을 추가하세요:
---
pretty_name: Terminal-Bench 2.0
tags:
...
이것이 전체 통합입니다. rl-environment는 유지하고, 파일을 로드할 수 있는 모든 프레임워크를 나열하세요. 만약 사용자의 환경이 아직 등록되지 않은 프레임워크와 작동한다면, 지원되는 라이브러리 목록에 PR(Pull Request)을 열어주세요.
문서(docs)에 전체 참조가 있습니다.
우리는 사람들이 이미 훈련하는 일부 환경에 태그를 지정하기 위해 PR(Pull Request)을 열었습니다. 만약 이들 중 하나를 유지 관리한다면, 해당 PR을 병합하고 여러분의 환경이 필터에 표시되도록 하세요.
Harbor
- BeyondSWE: Harbor 작업 디렉토리로 사용되는 BeyondSWE 벤치마크이며, 인스턴스당 하나의 폴더가 있습니다.
- Terminal-Lego: 실제 StackOverflow 이슈에서 구축된 Terminal-Bench 스타일의 작업으로, Docker 라운드 트립 검증을 거친 경우만 유지됩니다.
- Harbor-Mix: Harbor 어댑터 풀에서 선택한 100개의 어려운 에이전트(agentic) 작업을 포함하며, 전체 다중 벤치마크 스윕보다 실행 비용이 저렴합니다.
- NatureBench: Harbor용으로 사전 구축된 90개의 NatureBench 작업입니다.
Verifiers
- Reverse-Text-RL: prime-rl이 RL 훈련을 디버깅하기 위해 CI(Continuous Integration)에서 사용하는 작은 역전 작업입니다.
- Multi-SWE-RL-Verified: C, Go, Java, JavaScript, Rust, TypeScript 전반에 걸쳐 골드 패치 검증(gold-patch validation)을 통과한 4,703개 중 2,232개의 Multi-SWE-RL 행입니다.
- R2E-Gym-Subset-Verified: 검증된 R2E-Gym 서브셋입니다.
- Scale-SWE-Verified: 끝에서 끝까지 깨끗한 보상 신호(reward signal)를 제공하는 20,181개의 Python 이슈 해결 작업 중 17,202개입니다.
NeMo Gym
- Workplace Assistant: 다섯 개의 데이터베이스, 26개의 도구, 그리고 690개의 비즈니스 작업을 갖춘 다단계 도구 사용 샌드박스입니다.
- Structured Outputs: 구조화된 출력을 이용한 명령어 준수(instruction following) 기능입니다.
- CFBench: 다국어 제약 조건 준수 기능을 제공합니다.
- SysBench: 다중 턴 시스템 메시지 준수 기능을 제공합니다.
첫 번째 버전은 프레임워크당 하나의 default 스니펫을 생성합니다. 다음으로는 구성별(Per-config) 스니펫이 이어질 예정이며, 여러 작업 세트를 가진 저장소는 각 작업에 맞는 올바른 명령어를 표시할 수 있습니다. 그 이후에는 엄격한 레이아웃을 가진 프레임워크에 대한 구조적 감지(structural detection)를 살펴볼 것입니다. 또한 사용자 지정 작업 UI를 구축하는 것도 매우 좋을 것이며, 저희는 여기서 실험해 왔습니다:
더 큰 목표는 모든 곳에서 프레임워크 태그가 자동화되는 것입니다. OpenEnv는 이미 업로드 시 이를 수행합니다. 만약 여러분이 Harbor, Verifiers, Nemo Gym 또는 다른 환경/프레임워크를 유지 관리한다면, 푸시 경로에 태그를 추가해 주세요. 몇 줄의 코드로 모든 사용자가 게시하는 환경이 다른 사람들에게도 보이게 됩니다.
에이전트를 훈련한다면, 필터를 둘러보세요. 환경을 구축했다면, 코딩, 도구 사용, 게임, 로보틱스 또는 다른 작업을 다루는지 여부와 관계없이 게시하고 태그를 지정해 주세요. 파일과 작동하는 실행 명령어, 그리고 보상을 생성하는 규칙을 포함하여 다른 사람들이 사용할 수 있도록 해주세요. 만약 여러분의 프레임워크가 누락되었다면, 지원되는 라이브러리 목록에 기여해 주세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Hugging Face Blog의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기