상금 명세
목적. 이 문서는 MT Eval Arena의 상금 풀 구조, 임계 조건, 청구 절차, 규칙을 정의해요. "기계 번역이 가능하다"는 것이 측정 가능한 측면에서 정확히 무엇을 의미하는지, 그리고 어떤 조건에서 상금이 지급되는지 명시해요. 이 문서는 지표 정의에 대해 SCORING_SPEC을, 평가 프로토콜에 대해 BENCHMARK_SPEC을 참조하며, 이를 중복 기술하지는 않아요.
상태: LIVE. Founder's Prize(§2.1)는 자금이 조성되었고 활성화되어 있어요.
최종 업데이트: 2026-06-04
1. 철학
1.1 상금은 참여가 아닌 돌파구에 보상해요
상금은 어떤 방법이 정의된 역량 임계값을 입증 가능하게 달성했을 때에만 지급돼요. 참여상, 차점자상, 위로금 같은 것은 없어요. 아무도 기준을 통과하지 못하면 아무도 받지 못해요. 이는 의도된 설계로, 후원자는 실제로 작동하는 결과에만 비용을 지불한다는 것을 의미해요.
1.2 커뮤니티 검증은 타협 불가능해요
자동화된 지표는 대용물이에요(SCORING_SPEC §1.1). 어떤 방법이 chrF++와 FST 수용도에서는 좋은 점수를 내면서도 어떤 화자도 받아들이지 않을 출력을 생성할 수 있어요. 모든 상금 청구에는 커뮤니티 검증이 필요해요 — 이중 언어 화자가 출력이 사용 가능하다는 것을 확인해야 해요. 이것이 인간 검증 게이트예요(BENCHMARK_SPEC §7).
1.3 소유권 이전은 거래의 일부예요
상금을 청구하는 방법은 소유권 이전 조항(BENCHMARK_SPEC §8.3)의 적용을 받아요. 개발자는 저작자 표시 및 출판 권리를 유지해요. 거버넌스 조직은 해당 언어에 대해 그 방법을 사용, 수정, 배포, 수익화할 권리를 얻어요. 이는 벌칙이 아니라 핵심이에요. 상금은 언어 커뮤니티에 속하는 기술의 창출에 자금을 지원해요.
1.4 부정행위 방지
상금 임계값은 골드 스탠더드 평가(비밀 테스트 세트, 거버넌스 조직이 샌드박스에서 실행)를 기준으로 정의돼요. 개발자는 테스트 데이터를 절대 보지 못해요. 이는 신뢰에 의존하는 정책이 아니라 아키텍처적으로 강제돼요. BENCHMARK_SPEC §8.2를 참조하세요.
1.5 말뭉치 라이선스: 비상업적 말뭉치는 상금 레인 밖에 머물러요
방법 개발 중 사용되는 일부 말뭉치는 비상업적 라이선스를 지녀요 — 예를 들어 EdTeKLA Cree Language Textbook 말뭉치는 CC BY-NC-SA 4.0이에요. 이러한 말뭉치는 연구/개발 레인 전용이에요:
- 상금 골드 스탠더드 말뭉치에는 NC 라이선스 말뭉치 콘텐츠가 포함되어서는 안 돼요. 골드 스탠더드 테스트 세그먼트는 커뮤니티 위탁 원본이며(Corpus Partnership Strategy 참조), 상금을 위해 사람이 작성하고 처음부터 평가 및 상업적 배포에 대한 권리가 정리된 것이에요.
- 상금을 청구하는 방법에는 NC 라이선스 말뭉치 콘텐츠가 포함되어서는 안 돼요(예: 코칭 데이터, 임베디드 예제, 룩업 테이블 등). 이전된 방법은 거버넌스 조직의 상업적 배포를 위한 것이며(BENCHMARK_SPEC §8.3, Method Submission Agreement §6), 그 안에 NC 라이선스 콘텐츠가 있으면 해당 배포를 오염시켜요.
- 개발자는 NC 라이선스 말뭉치를 개발 및 자체 평가에 자유롭게 사용할 수 있어요 — 그것이 개발 레인의 목적이에요. 이 제한은 제출되는 것과 배포되는 것에 적용되며, 개발자가 학습하는 방식에는 적용되지 않아요.
1.6 종속성 클래스가 상금 자격을 결정해요
모든 상금 평가는 샌드박스에서 이루어지며(§1.4), 상금 수상 방법은 거버넌스 조직으로 이전돼요(§1.3). 두 사실 모두 동일한 제약을 부과해요: 방법이 의존하는 모든 것은 개발자가 샌드박스에 넣고 커뮤니티에 양도할 권리를 가진 것이어야 해요. 모든 제출물은 종속성 클래스를 선언하며 — Method Interface spec에 정의되어 있고, 허용 조건은 Method Submission Agreement §2.6에 있어요 — 자격은 클래스에 따라 결정돼요:
| 종속성 클래스 | 상금 자격 여부 | 조건 |
|---|---|---|
| S — 자체 완결형 | ✅ 예 | §2의 임계 조건 외에는 없음 |
| O — 오픈 외부형(예: 제출 시점에 미러링된 AGPL FST) | ✅ 예 | 아티팩트가 제출물에 고정 및 벤더링됨; 라이선스가 커뮤니티 이전을 허용함; 카피레프트 조건 유지됨(커뮤니티는 라이선스가 모두에게 부여하는 동일한 권리를 받음) |
| A1 — 대체 가능한 LLM 추론 | ⚠️ 조건부 | 모델이 선언, 고정, 대체 가능함(커뮤니티 호스팅 오픈 웨이트 모델에 대해 실행되어야 함); 평가가 샌드박스 LLM 게이트웨이를 통해 라우팅됨(🔲 계획됨 — 게이트웨이가 작동하기 전까지 A1 방법은 골드 스탠더드 점수를 생성할 수 없음); 이전 시 모델이 아닌 전체 레시피(프롬프트, 코칭, 코드)가 양도됨 |
| A2 — 대체 불가능한 외부 데이터/서비스 API | ❌ 아직 아님 | 권리 보유자가 샌드박스 포함 및 이전 권한을 부여할 때까지 자격 없음. 표시되는 "외부 종속성" 플래그와 함께 오픈 리더보드에서 허용됨 |
| X — 권리 없는 번들 콘텐츠 | ❌ 절대 아님 | 모든 레인에서 허용 불가 |
방법의 클래스는 선언된 종속성 중 가장 제한적인 클래스예요. 어떤 클래스든 선언되지 않은 종속성은 자격 박탈 사유예요(§5).
2. 활성 상금 풀
2.1 Founder's Prize — EN→Plains Cree (nêhiyawêwin)
| 항목 | 값 |
|---|---|
| 상금 풀 | $10,000 CAD |
| 언어 쌍 | English → Plains Cree (EN→CRK) |
| 자금 지원 | Champollion project 창립자 |
| 상태 | ACTIVE — 제출 접수 중 |
| 개시 | 골드 스탠더드 말뭉치 + 거버넌스 조직이 갖춰졌을 때 |
| 만료 | 만료 없음. 청구되거나 명시적으로 철회될 때까지 상금은 활성 상태로 유지돼요. |
임계 조건
방법은 다음 조건을 모두 동시에 충족함으로써 Founder's Prize를 청구해요:
| # | 조건 | 지표 | 임계값 | 근거 |
|---|---|---|---|---|
| 1 | 복합 점수 | composite (SCORING_SPEC §4) | ≥ 0.80 | Deployable(0.70)과 Fluent(0.85) 사이. 형태론적 유효성뿐 아니라 모든 지표 차원에서 높은 품질을 요구함. |
| 2 | FST 수용도 | fst_acceptance_rate (SCORING_SPEC §2.2) | ≥ 0.99 (99%+) | 사실상 모든 출력 단어가 GiellaLT FST에 의해 인식되는 형태론적으로 유효한 형태여야 함. 1% 허용치는 FST가 정당하게 포함하지 못할 수 있는 엣지 케이스(고유명사, 신조어, 차용어)를 고려한 것임. 이것이 다종합어 MT의 핵심 품질 게이트임 — FST가 단어의 1% 이상을 거부하면, 그 방법은 해당 언어에 존재하지 않는 형태를 생성하고 있는 것임. 이 상금의 핵심 취지는 언어를 망가뜨리지 않는 시스템을 구매하는 것임. |
| 3 | chrF++ | chrf_plus_plus (SCORING_SPEC §2.1) | ≥ 55.0 | 문자 n-gram 중첩이 0–100 척도에서 55를 초과해야 함. 형태론적 유효성뿐 아니라 참조 번역과의 표면 수준 유사성을 보장함. |
| 4 | 커뮤니티 검증 | 인간 검토 (BENCHMARK_SPEC §7) | ≥ 70% "acceptable" 또는 "excellent" | 출력의 계층화된 표본(난이도 등급 2–5에 걸친 ≥30개 항목)을 ≥2명의 이중 언어 CRK 화자가 검토함. 검토된 항목의 최소 70%가 "acceptable" 또는 "excellent" 등급을 받아야 함. |
| 5 | 골드 스탠더드 평가 | 샌드박스 실행 (BENCHMARK_SPEC §8.2) | 필수 | 모든 자동화 지표는 거버넌스 조직이 샌드박스 환경에서 실행하는 gold_standard 말뭉치 세그먼트를 기준으로 계산되어야 함. 개발 세트 점수는 인정되지 않음. |
| 6 | 재현성 | 핑거프린트 일치 (BENCHMARK_SPEC §3.8) | ±2% | 거버넌스 조직이 방법을 재실행하여 제출된 run card의 ±2% 이내 점수를 달성할 수 있어야 함. |
왜 99+% FST인가요? 다종합어의 기계 번역에서 핵심 문제는 환각이에요 — LLM은 대상 언어처럼 보이지만 형태론적으로 유효하지 않은 문자열을 생성해요. 95% 유효 출력을 생성하는 방법도 5%의 조작된 단어를 가지며, 이는 어떤 프로덕션 용도에서도 용납할 수 없는 잡음이에요. 99%+ 임계값은 드문 엣지 케이스(FST가 모르는 고유명사, 정당한 신조어)를 허용하면서도 환각이 거의 없을 것을 요구해요. 방법이 99%+ FST 수용도를 달성할 수 없다면, 문제를 해결하지 못한 거예요.
왜 0.80 복합 점수인가요? 이는 Deployable(0.70)과 Fluent(0.85) 사이에 위치해요. 99%+ FST 수용도를 갖춘 0.80의 방법은 사실상 모든 단어가 진짜 Cree 단어이고 동시에 전반적인 번역 품질이 표면, 구조, 의미 차원 전반에서 높은 출력을 생성해요. 커뮤니티 검증 게이트(조건 #4)는 이것이 단순한 지표 부정행위가 아님을 보장해요 — 화자가 출력이 진정으로 사용 가능하다는 것을 확인해야 해요.
이 임계값이 실제로 의미하는 것
복합 점수 ≥ 0.80, FST ≥ 0.99, chrF++ ≥ 55에서 이중 언어 화자는 일반적으로 다음을 보게 돼요:
- 사실상 모든 출력 단어가 진짜 Cree 단어임 (FST가 99%+ 검증 — 조작된 형태가 거의 없음)
- 주요 문법 범주(인칭, 수, 시제)가 대부분의 항목에서 정확함
- 어순이 대체로 자연스러움
- 의미가 안정적으로 보존됨
- 남은 오류는 실제 언어 오류(잘못된 굴절, 부정확한 obviation, 유생성 불일치)이며 — 조작된 단어가 아님
- 유창한 화자가 출력을 고품질 초안으로 사용하고, 처음부터 번역하는 것보다 훨씬 빠르게 수정할 수 있음
이것은 언어를 망가뜨리지 않는 시스템이에요. 완벽하지 않을 수 있지만, 생성하는 모든 단어가 진짜 단어예요. 그것이 다종합어의 존중하는 기계 번역을 위한 최소 기준이에요.
3. 상금 청구 절차
3.1 제출
-
개발자는 완전하고 실행 가능한 방법을 거버넌스 조직에 제출해요:
- 모든 소스 코드
- 모든 종속성(코칭 데이터, 사전, FST 설정, 프롬프트)
- 설치 및 실행 지침
- 방법의 접근법을 설명하는 README
- 대략적인 점수를 보여주는 개발 세트 run card(사전 심사용)
-
개발자는 다음을 포함한 참여 조건에 서명해요:
- 소유권 이전 조항 (BENCHMARK_SPEC §8.3)
- 평가 데이터로 학습하지 않았다는 선언
- 재현성 약속
3.2 평가
- 거버넌스 조직이
gold_standard말뭉치를 기준으로 샌드박스 하니스에서 방법을 설치하고 실행해요 - 자동화 지표가 계산돼요(복합 점수, FST, chrF++ 등)
- 자동화 임계값이 충족되면(조건 1–3) 거버넌스 조직은 커뮤니티 검토로 진행해요
- 자동화 임계값이 충족되지 않으면 개발자는 점수와 피드백을 받아요. 커뮤니티 검토는 시작되지 않아요.
3.3 커뮤니티 검토
- 출력의 계층화된 표본(난이도 등급 2–5를 포괄하는 ≥30개 항목)이 이중 언어 화자에게 제시돼요
- 최소 2명의 독립 검토자가 각 항목을 평가해요
- 평가 척도: reject / gist / acceptable / excellent
- 항목의 ≥70%가 두 검토자 모두로부터 "acceptable" 또는 "excellent"를 받으면 커뮤니티 검증을 통과해요
3.4 지급
- 6가지 조건이 모두 충족돼요
- 거버넌스 조직이 결과를 확인해요
- 확인 후 30일 이내에 상금이 지급돼요
- 방법 소유권이 BENCHMARK_SPEC §8.3에 따라 이전돼요
- 결과가 "Community Validated" 검증 등급과 함께 리더보드에 게시돼요
3.5 다중 제출
- 동일한 개발자/팀이 여러 번 제출할 수 있어요
- 각 제출물은 독립적으로 평가돼요
- 방법이 개선되어 재제출되면 최신 run card만 인정돼요
- 상금은 모든 임계값을 통과하는 첫 번째 방법에 수여되며, 분할되지 않아요
3.6 팀 제출
- 팀과 Elder-youth 페어가 자격이 있어요
- 팀 내 상금 분배는 팀의 책임이에요
- 모든 팀원은 참여 조건에 서명해야 해요
- 리더보드의 저작자 표시에는 모든 팀원이 나열돼요
4. 향후 상금 풀
Founder's Prize는 씨앗이에요. 추가 상금 풀은 후원자가 자금을 지원해요. 각 새로운 상금 풀은 §2의 새로운 하위 절로 다음 항목과 함께 문서화돼요:
- 상금 액수 및 통화
- 언어 쌍
- 후원자 저작자 표시
- 임계 조건(Founder's Prize와 다를 수 있음)
- 만료일(있는 경우)
- 특별 조건
4.1 후원자 상금 템플릿
후원자는 어떤 금액으로든 상금 풀에 자금을 지원해요. 권장 등급:
| 등급 | 금액 | 권장 임계값 |
|---|---|---|
| Seed | $5,000–$15,000 | Deployable (복합 점수 ≥ 0.70) + 커뮤니티 검증 |
| Breakthrough | $25,000–$50,000 | Fluent (복합 점수 ≥ 0.85) + 커뮤니티 검증 |
| Grand Prize | $100,000+ | Fluent + 다중 레지스터 커버리지 + 배포 통합 |
후원자는 다음에도 자금을 지원할 수 있어요:
- 개선 현상금 — 현재 최고 대비 chrF++가 5점 개선될 때마다 고정 지급
- 레지스터 상 — 특정 레지스터(격식, 의례, 교육)에 대한 별도 시상
- 속도 상 — 최고의 비용 조정 점수 (SCORING_SPEC §6.3)
4.2 상금 풀 에스크로
모든 상금 자금은 임계 조건이 충족될 때까지 에스크로(프로젝트 또는 지정된 수탁자가 관리)에 보관돼요. 상금이 청구되지 않고 만료되면, 자금은 후원자에게 반환되거나 후원자의 재량에 따라 새로운 상금 풀로 전용돼요.
5. 자격 박탈
다음의 경우 제출물은 자격이 박탈돼요:
- 평가 데이터로 학습. 방법이
gold_standard또는held_out말뭉치 항목에 노출됨. (샌드박스 실행으로 아키텍처적으로 방지되지만 — 오염의 증거가 발견되면 결과가 무효화됨.) - 재현 불가능. 거버넌스 조직이 ±2% 이내로 점수를 재현할 수 없음.
- 선언되지 않았거나 자격 없는 종속성. 방법이 종속성 매니페스트가 선언하는 것을 넘어 외부 서비스에 대한 런타임 접근을 요구하거나, 실효 종속성 클래스가 A2 또는 X임(§1.6). 평가 게이트웨이를 통해 라우팅되는 선언된 Class A1 LLM 추론은 허용됨; 그 외의 런타임 네트워크 종속성 — 그리고 어떤 클래스든 선언되지 않은 종속성 — 은 자격 박탈 사유임.
- 참여 조건 미서명. 모든 팀원은 소유권 이전에 동의해야 함.
- 부정행위 감지. 출력이 번역 품질이 아닌 지표에 최적화됨(커뮤니티 검토 및/또는 BENCHMARK_SPEC §9.3에 따른 부정행위 방지 검사로 적발됨).
6. 다른 명세와의 관계
| 이 문서 | 참조 | 용도 |
|---|---|---|
| §2 임계 조건 | SCORING_SPEC §4 (복합 점수), §2.1–2.2 (지표), §5 (등급) | 지표 정의 및 척도 |
| §2 커뮤니티 검증 | BENCHMARK_SPEC §7 | 인간 검토 프로토콜 |
| §3 샌드박스 실행 | BENCHMARK_SPEC §8.2 | 주권 메커니즘 |
| §3 소유권 이전 | BENCHMARK_SPEC §8.3 | IP 이전 조건 |
| §1.6 종속성 클래스 | Method Interface spec; Method Submission Agreement §2.6; BENCHMARK_SPEC §8.6 | 클래스 정의, 허용 조건, 샌드박스 네트워크 정책 |
| §4 비용 조정 상금 | SCORING_SPEC §6.3 | 비용 조정 공식 |
7. 코드–명세 동기화
7.1 정본 출처
이 문서(arena/website/docs/specifications/prize-spec.md)는 다음의 정본 출처예요:
- 상금 풀 정의 (§2)
- 임계 조건 (§2.x)
- 청구 절차 (§3)
- 자격 박탈 규칙 (§5)
7.2 구현 요구사항
상금 풀이 활성화될 때:
- 리더보드 UI는 활성 상금과 그 임계 조건을 표시해야 해요
- 자동화 임계값을 충족하는 run card(조건 1–3)는 커뮤니티 검토를 위해 플래그가 지정되어야 해요
- run card 스키마의
quality_tier필드는 이미 등급("deployable", "fluent")을 포착해요 - 하니스에 대한 새로운 코드 변경은 필요하지 않아요 — 상금 명세는 기존 채점 위에 놓이는 정책 계층이에요
상금 구조는 소유권 이전 조건과 호환되어야 해요. 수상자는 상금을 청구할 수 있지만, 방법이 Deployable 등급에 도달하면 그 방법은 거버넌스 조직의 자산이 돼요. 이는 의도된 설계예요 — 상금은 언어 커뮤니티에 속하는 기술의 창출에 자금을 지원해요.