코퍼스 파트너십 전략: 학술 언어학과를 통한 평가 코퍼스 구축
목적. 이 문서는 언어학과 파트너십을 통해 기계 번역 평가 코퍼스를 구축하기 위한 완전한 워크플로를 제공해요. 학과가 제공해야 할 것, 코퍼스가 갖춰야 할 형태, 암호학적으로 봉인되는 방식, 샌드박스 평가의 작동 방식, 그리고 학과가 그 대가로 얻는 것을 다뤄요. 잠재적 학술 파트너와의 미팅에 가져갈 문서예요.
대상 독자. 활발한 언어 문서화 또는 NLP 프로그램을 운영하는 대학의 학과장, 책임 연구자, 연구 코디네이터, 원주민 언어 프로그램 책임자.
관련 문서:
- Speaker Validation Protocol — 이중 언어 화자에게 기존 번역을 표시하도록 요청하는 것(품질 평가, 린터 검증, FST 검토)
- Benchmark Specification — 코퍼스, 실행 카드, 평가 프로토콜에 대한 전체 기술 사양
- Data Sovereignty — OCAP®, CARE, 그리고 소유권 이전이 중요한 이유
최종 업데이트: 2026-06-07
1. 이 파트너십이 만들어내는 것
봉인된 평가 코퍼스: 기계 번역 품질을 측정하기 위한 그라운드 트루스가 되는, 큐레이션된 병렬 텍스트 쌍 집합(원본 언어 → 대상 언어)이에요. 방법들은 샌드박스에서 이 코퍼스를 대상으로 테스트되며, 개발자는 테스트 데이터를 절대 볼 수 없어요.
이 파트너십은 세 가지 산출물을 만들어내요:
| 산출물 | 무엇인가 | 누가 통제하는가 |
|---|---|---|
| 개발 코퍼스 | 방법 개발을 위한 100~200개 이상의 공개 병렬 텍스트 쌍 | 공개적으로 게시(CC BY-NC-SA 4.0 또는 동등 라이선스) |
| 골드 스탠더드 테스트 세트 | 공식 평가를 위한 50~150개의 비공개 병렬 텍스트 쌍 | 커뮤니티 거버넌스 조직(암호학적으로 봉인) |
| 진단 테스트 스위트 | 특정 언어 현상을 테스트하는 10~50개의 표적 대조 쌍 | 공개적으로 게시 |
개발 코퍼스는 누구나 번역 방법을 구축할 수 있게 해줘요. 골드 스탠더드 세트는 그러한 방법들이 정직하게 테스트되도록 보장해요. 진단 스위트는 특정 실패 모드(예: "이 시스템이 obviation을 처리할 수 있는가?")를 잡아내요.
2. 학과가 해야 할 일
1단계: 코퍼스 설계 (2~4주, 연구자 시간)
주도: 대상 언어 전문성을 갖춘 책임 연구자 또는 박사 후 연구원.
-
소스 자료 도메인 선택. 언어 커뮤니티가 실제로 번역을 필요로 하는 4~6개의 실제 도메인을 선택해요. 우리의 분류 체계는 16개 도메인을 지원해요(Benchmark Spec §2.7 참조):
우선순위 도메인 이유 🔴 높음 edu— Educational교과서, 커리큘럼 — 직접적인 커뮤니티 필요 🔴 높음 gov— Government밴드 의회 문서, 정책 — 실질적인 일상적 필요 🔴 높음 medical— Health진료 접수 양식, 건강 정보 — 안전 핵심 🟡 중간 conv— Conversational일상 대화 — 기본 유창성 확립 🟡 중간 legal— Legal권리 문서, 조약 — 커뮤니티 중요성 🟢 낮음 literary— Literary/Cultural이야기, 구전 역사 — 문화 보존 -
코퍼스 설계 문서 작성 — 다음을 명시해요:
- 세그먼트별 목표 크기(development, gold_standard, diagnostic)
- 난이도 등급 분포(아래 §3.3 참조)
- 레지스터 및 도메인 범위
- 소스 문장 선택 기준(합성 텍스트 금지, 성경 전용 금지)
- 화자 모집 계획
-
설계를 검토용으로 우리에게 제출. 우리는 코퍼스 스키마(Benchmark Spec §2)에 대해 이를 검증하고 1주일 이내에 피드백을 드려요.
2단계: 소스 문장 생성 (4~8주, 화자 시간)
주도: 이중 언어 화자와 협력하는 연구 코디네이터.
-
계획된 도메인과 난이도 등급에 걸쳐 소스 문장을 생성하거나 선택. 소스는 다음일 수 있어요:
- 기존에 게시된 이중 언어 자료(교과서, 정부 문서)
- 특정 언어 현상을 다루도록 설계되어 새로 수집된 문장
- 실제 문서에서 각색한 것(밴드 의회 안건, 진료 양식, 교육 자료)
-
각 소스 문장은 다음을 갖춰야 해요:
- 도메인 태그(16개 코드 분류 체계에서)
- 레지스터 태그(conversational, formal, technical, ceremonial, educational)
- 컨텍스트 태그(greeting, declaration, question, instruction, narrative, label, error)
- 추정 난이도 등급(1~5, §3.3 참조)
- 출처 태그(textbook, elicited, corpus, gold_standard)
-
각 소스 문장을 대상 언어로 번역 — 이중 언어 화자가 수행해요. 항목당 여러 참조 번역이 있으면 가치가 있지만 필수는 아니에요.
-
선택적으로, 각 참조 번역에 형태론적 분석 추가:
- 행간 주석(형태소별 분해)
- FST 태그 문자열(해당 언어에 FST가 존재하는 경우)
- 방언 변형, 모호성, 또는 문화적 맥락에 대한 번역가 노트
3단계: 품질 보증 (2~4주)
주도: 대상 언어 전문성을 갖춘 언어학자.
-
교차 검토. 각 번역은 원래 번역을 만들지 않은 추가 이중 언어 화자 한 명 이상이 검토해야 해요. 검토자는 다음을 확인해요:
- 번역이 정확한가?
- 자연스럽게 들리는가?
- 난이도 평가가 올바른가?
- 명시되어야 할 허용 가능한 변형이 있는가?
-
우리 스키마 검증기를 통해 실행. 우리는 항목 스키마(Benchmark Spec §2.2)에 대해 코퍼스를 검증하는 스크립트를 제공해요. 이는 다음을 확인해요:
- 필수 필드 존재 여부
- 도메인 코드 유효성
- 난이도 등급이 1~5 정수인지
- 중복 ID 없음
- 문자 인코딩(UTF-8 NFC 정규화)
-
해당 언어에 FST가 존재하는 경우, 참조 번역을 그 FST를 통해 실행해요. 참조의 모든 단어는 FST 유효여야 해요. 그렇지 않은 단어(차용어, 신조어, 고유명사)는 허용 목록에 문서화해야 해요.
4단계: 세그먼트 분할 및 봉인 (1주, 우리 엔지니어링)
주도: Champollion 팀, 학과 검토 포함.
-
계층화 분할. 우리는 결정론적 무작위 샘플링(시드 문서화, 재현 가능)을 사용해 코퍼스를 세그먼트로 분할해요:
세그먼트 목표 크기 접근 development항목의 60%(최소 100) 공개 gold_standard항목의 30%(최소 50) 비공개, 봉인 held_out항목의 10%(최소 10) 비공개, 봉인, 활성화될 때까지 사용 안 함 분할은 난이도 등급 분포를 보존(계층화 샘플링)하여 각 세그먼트가 등급 전반에 걸쳐 비례적으로 대표되도록 해요.
-
gold_standard 및 held_out 세그먼트의 암호학적 봉인:
1. SHA-256 hash of each entry (source + reference + metadata)2. SHA-256 hash of the complete segment file3. Segment file encrypted with AES-256-GCM4. Encryption key split using Shamir Secret Sharing (2-of-3 threshold)5. Key shares distributed to:- Share 1: Community governance organization- Share 2: Academic department partner- Share 3: Champollion project (escrow)6. Hash manifest published to a public commit (proves the corpus existedat a specific time without revealing its contents) -
development 세그먼트는 공개 저장소에 커밋되고 전체 라이선스와 함께 게시돼요.
-
diagnostic 세그먼트도 공개되며, 특정 언어 현상을 테스트해요(§3.4 참조).
5단계: 통합 및 출시 (1~2주, 우리 엔지니어링)
-
하니스 구성. 우리는 언어를 평가 하니스에 추가해요:
- 언어 카드 생성 또는 검증
- 데이터셋 레지스트리에 코퍼스 등록
- LYSS 메트릭 구성(FST가 있으면 LYSS-fst, 린터 규칙이 있으면 LYSS-eq)
- 기본 채점 프로파일 선택(FST가 있으면 Profile A, 그렇지 않으면 Profile B)
-
베이스라인 벤치마크. 우리는 development 세그먼트를 대상으로 12개 모델 스윕을 실행하여 초기 점수로 리더보드를 채워요.
-
공개 발표. 해당 언어가 라이브 development 세그먼트 벤치마크와 함께 Arena 리더보드에 나타나요. 학과는 코퍼스 파트너로 명시돼요.
3. 코퍼스가 갖춰야 할 형태
3.1 형식
모든 코퍼스 파일은 Benchmark Spec §2.1~§2.2의 스키마를 따르는 JSON 문서예요:
{
"dataset": {
"id": "crk-ualberta-v1",
"version": "1.0",
"language_pair": "EN→CRK",
"source_language": "en",
"target_language": "crk",
"created": "2026-09-15",
"license": "CC-BY-NC-SA-4.0",
"provenance": ["textbook", "elicited", "gold_standard"]
},
"entries": [
{
"id": 1,
"source": "I see the dog",
"reference": "niwâpamâw atim",
"segment": "development",
"difficulty": 2,
"provenance": "textbook",
"register": "conversational",
"context": "declaration",
"domain": "edu",
"morphological_analysis": "ni-wâpam-âw atim | 1sg-see.TA-3sg.DIR dog.AN",
"notes": "Animate noun (atim); direct form because speaker is proximate"
}
]
}
3.2 최소 크기 요건
| 세그먼트 | 최소 항목 수 | 권장 |
|---|---|---|
development | 100 | 200~300 |
gold_standard | 50 | 100~150 |
diagnostic | 10 | 30~50 |
held_out | 10 | 20~30 |
| 총계 | 170 | 350~530 |
3.3 난이도 분포
코퍼스는 다섯 가지 난이도 등급 전반에 걸친 항목을 포함해야 하며, 2~4등급에 가중치를 둬요:
| 등급 | 설명 | 목표 분포 |
|---|---|---|
| 1 — 기본 어휘 | 단일 단어, 일반적인 인사말, 숫자 | 10~15% |
| 2 — 단순 문장 | SVO, 현재 시제 | 25~30% |
| 3 — 중간 복잡도 | 과거/미래 시제, 소유격, 유정성 | 30~35% |
| 4 — 복잡한 형태론 | obviation, 수동태, conjunct order, 관계절 | 15~20% |
| 5 — 고급 | 다중 절, 격식 레지스터, 의례적, 관용적 | 5~10% |
3.4 진단 테스트 스위트
diagnostic 세그먼트는 대조 쌍을 사용해 특정 언어 현상을 테스트해요: 올바른 번역 하나와 최소한으로 차이 나는 잘못된 번역 하나. 시스템의 메트릭이 올바른 쪽에 더 높은 점수를 매기면 테스트를 통과해요.
다합성 언어의 경우, 진단 스위트는 다음을 표적으로 삼아야 해요:
| 현상 | 예시(Cree) | 테스트하는 것 |
|---|---|---|
| 유정성 일치 | atim (AN) vs. maskisin (IN) — 서로 다른 동사 형태 | 시스템이 어떤 명사가 유정인지 아는가? |
| Obviation | 근칭 vs. obviative 3인칭 | 3인칭 위계를 추적하는가? |
| 역 표시 | 직접 vs. 역 동사 형태 | 피동작주가 동작주보다 우위인 경우를 처리하는가? |
| Conjunct/Independent | 주절 vs. 종속절 동사 어순 | 올바른 동사 패러다임을 사용하는가? |
| 포함/배제 | "우리(당신 포함)" vs. "우리(당신 제외)" | 1인칭 복수 형태를 구별하는가? |
다른 어족의 경우, 유능한 번역과 무능한 번역을 구별하는 가장 진단적인 3~5개 현상을 식별해요. 이 부분에서는 학과의 언어학 전문성이 필수적이에요 — 이는 전문가만이 작성할 줄 아는 테스트예요.
3.5 우리가 원하지 않는 것
| 안티 패턴 | 이유 |
|---|---|
| 성경 전용 텍스트 | 고풍스러운 레지스터, 전례 어휘, 정형화된 구조. OMT-1600은 1,560개 언어를 이런 방식으로 평가했어요 — 우리는 이를 의도적으로 피해요. |
| 합성 평가 쌍 | LLM이 생성한 참조는 평가의 목적을 무력화해요. 참조는 사람이 작성해야 해요. |
| 단일 레지스터 코퍼스 | 전부 격식체이거나 전부 대화체. 실제 번역은 여러 레지스터에 걸쳐 있어요. |
| 난이도-1 전용 | 단일 단어와 인사말은 번역을 테스트하지 않아요 — 어휘 검색을 테스트할 뿐이에요. |
| 기계 번역 참조 | Google Translate 출력을 "참조"로 사용하는 것은 순환적이에요. |
| 컨텍스트 태그가 없는 문장 | 진단 분석을 위해 의사소통 기능을 알아야 해요. |
4. 암호학적 봉인 및 샌드박스 테스트
4.1 테스트 세트를 봉인하는 이유는?
일반적인 ML 벤치마크는 테스트 세트를 공개적으로 게시해요. 일단 게시되면, 프런티어 LLM은 결국 그것으로 학습하게 되어(의도적으로든 웹 스크래핑을 통해서든) 점수를 신뢰할 수 없게 만들어요. 원주민 언어 데이터의 경우 추가적인 우려가 있어요: 게시된 언어 데이터는 커뮤니티 동의 없이 사용될 수 있어요.
봉인은 다음을 보장해요:
- 테스트 세트 무결성: 방법들은 본 적 없는 데이터에 과적합할 수 없어요
- 데이터 주권: 커뮤니티가 자신들의 데이터를 대상으로 누가 평가하는지 통제해요
- 영구적 신선도: 테스트 세트는 결코 오염되지 않아요
4.2 샌드박스 테스트의 작동 방식
Developer workflow:
1. Developer builds a translation method using the PUBLIC development corpus
2. Developer tests locally against the development segment (unlimited, self-serve)
3. When ready, developer submits their complete method (code + config + coaching data)
4. Governance org installs the method in the evaluation sandbox
5. Sandbox runs the method against the SEALED gold-standard test set
6. Only scores are returned to the developer
7. Developer never sees the source sentences or reference translations
The sandbox:
- Runs on governance-controlled infrastructure
- Has selective network access (LLM APIs only, no exfiltration)
- Produces a tamper-proof run card (SHA-256 hash of all inputs and outputs)
- Logs all execution for audit purposes
- Can be inspected by the governance org at any time
4.3 키 관리
봉인된 테스트 세트의 암호화 키는 2-of-3 임계값으로 Shamir Secret Sharing을 사용해 분할돼요:
| 분할 보유자 | 역할 | 철회 권한 |
|---|---|---|
| 커뮤니티 거버넌스 조직 | 주 관리자 | 평가 접근을 일방적으로 철회할 수 있음 |
| 학술 학과 파트너 | 공동 관리자 | 키 재구성에 참여할 수 있음 |
| Champollion 프로젝트 | 에스크로 | 단독으로 데이터에 접근할 수 없음; 다른 당사자가 부재할 경우 연속성 보장 |
3개 중 어느 2개의 분할이든 키를 재구성해요. 이는 다음을 의미해요:
- 커뮤니티 + 학과는 Champollion 없이 데이터에 접근할 수 있어요
- 커뮤니티 + Champollion은 학과 없이 데이터에 접근할 수 있어요
- Champollion 단독으로는 결코 데이터에 접근할 수 없어요
4.4 해시 매니페스트
코퍼스가 봉인되면, 해시 매니페스트가 공개 Git 커밋에 게시돼요:
{
"corpus_id": "crk-ualberta-v1",
"seal_date": "2026-09-15T00:00:00Z",
"segments": {
"development": {
"entry_count": 200,
"sha256": "a3f7c...",
"access": "public"
},
"gold_standard": {
"entry_count": 100,
"sha256": "b8d2e...",
"access": "sealed",
"key_scheme": "shamir-2-of-3"
},
"held_out": {
"entry_count": 20,
"sha256": "c9e4f...",
"access": "sealed",
"key_scheme": "shamir-2-of-3"
},
"diagnostic": {
"entry_count": 30,
"sha256": "d1a3b...",
"access": "public"
}
},
"total_entries": 350,
"manifest_sha256": "e2b5c..."
}
이는 다음을 증명해요:
- 코퍼스가 특정 날짜에 존재했음
- 알려진 크기와 구조를 가지고 있음
- 봉인된 세그먼트에 대한 어떠한 수정도 해시 체인을 깨뜨림
- 커뮤니티가 자신들의 데이터가 변조되지 않았음을 검증할 수 있음
5. 학과가 얻는 것
5.1 연구 인프라
| 자산 | 설명 |
|---|---|
| 평가 하니스 | 자신들의 언어를 위해 작동하고 테스트된 평가 프레임워크 — 수개월의 도구 구축 시간을 절약 |
| LYSS 메트릭 | 자신들의 언어에 맞게 구성된 언어별 평가 메트릭(LYSS-fst, LYSS-eq, LYSS-sem) — FST 및 사전 자원이 존재하는 경우 |
| 리더보드 | 자신들의 언어 쌍에 대한 최신 기술 수준을 보여주는 공개 라이브 리더보드 |
| 베이스라인 벤치마크 | 즉시 게시 가능한 베이스라인을 제공하는 12개 모델 스윕 |
| 진단 테스트 스위트 | 특정 언어 현상을 위한 표적 테스트 — 다른 평가에 재사용 가능 |
5.2 출판물
코퍼스 구축 및 평가 결과는 여러 출판물을 뒷받침해요:
| 논문 | 발표 장소 | 학과 역할 |
|---|---|---|
| 코퍼스 구축 방법론 | LREC, ComputEL | 주저자 또는 공동저자 |
| 베이스라인 평가 결과 | ACL, EMNLP | 공동저자 |
| LYSS 메트릭 검증 | WMT Metrics Shared Task | 공동저자 |
| 진단 테스트 스위트 설계 | SIGMORPHON, NAACL | 주저자 또는 공동저자 |
| 언어별 NLP 자원 | 언어별 발표 장소 | 주저자 |
5.3 보조금 포지셔닝
이 파트너십은 보조금 제안서를 위한 구체적인 산출물을 제공해요:
- "[언어] MT를 위한 오픈소스 평가 인프라" — 입증 가능한 산출물
- "원주민 언어 데이터를 위한 암호학적 데이터 주권" — 참신하고 출판 가능
- "라이브 리더보드를 갖춘 커뮤니티 거버넌스 벤치마크" — 지속적인 영향 지표
- "[언어]에 대한 OMT-1600 / Google Translate의 독립 평가" — 시의적절하고 높은 가시성
5.4 커뮤니티 영향
- 언어 커뮤니티는 독립적인 평가 역량을 얻어요 — 어떤 MT 시스템(Google, Meta, 또는 맞춤형)이든 자신들의 언어에서 실제로 작동하는지 평가할 수 있어요
- 커뮤니티는 암호화 키 관리를 통해 테스트 데이터를 통제해요
- 벤치마크를 통해 입증된 모든 방법은 소유권을 커뮤니티로 이전해요(Benchmark Spec §8.3 참조)
- 배포된 방법으로부터 발생하는 수익이 커뮤니티로 흘러가요(90/10 분배)
5.5 학과가 부담하는 비용
| 구성 요소 | 추정 비용 | 부담 주체 |
|---|---|---|
| 책임 연구자/박사 후 연구원 시간(설계, 감독) | 약 40시간 | 학과(또는 보조금 지원) |
| 화자 보상(번역) | $2,500~6,000 | 보조금 지원 또는 Champollion 지원 |
| 화자 보상(검토) | $500~1,500 | 보조금 지원 또는 Champollion 지원 |
| 연구 코디네이터 시간 | 약 20시간 | 학과 |
| 엔지니어링, 인프라, 하니스 | $0 | Champollion 프로젝트 |
우리는 모든 엔지니어링, 하니스 구성, LYSS 메트릭 설정, 리더보드 통합, 그리고 지속적인 인프라를 학과에 비용 부담 없이 제공해요. 학과의 기여는 언어학 전문성과 화자 접근이에요.
6. 타임라인
| 단계 | 기간 | 핵심 마일스톤 |
|---|---|---|
| 1: 코퍼스 설계 | 2~4주 | 설계 문서 승인 |
| 2: 소스 문장 + 번역 | 4~8주 | 원시 코퍼스 완료 |
| 3: 품질 보증 | 2~4주 | 교차 검토, 스키마 검증 완료 |
| 4: 봉인 | 1주 | 골드 스탠더드 봉인, 해시 매니페스트 게시 |
| 5: 통합 | 1~2주 | 베이스라인과 함께 언어가 리더보드에 라이브 |
| 총계 | 10~19주 | 봉인된 평가를 갖춘 라이브 리더보드 |
7. 시작하는 방법
-
우리에게 연락 — [프로젝트 이메일/연락처]. 당신의 언어, 사용 가능한 자원, 파트너십 관련 사항을 논의하기 위해 30분 통화를 일정 잡을게요.
-
우리가 제공하는 것:
- 이 문서
- 코퍼스 스키마 및 검증 도구
- 기존 Cree(CRK) 코퍼스의 예시
- 코퍼스 설계 템플릿 초안
-
당신이 제공하는 것:
- 언어학 작업을 주도할 책임 연구자 또는 박사 후 연구원
- 이중 언어 화자에 대한 접근(또는 모집 계획)
- 사용 가능한 자원에 대한 정보(FST, 사전, 기존 코퍼스)
- 데이터 거버넌스에 대한 기관 승인(OCAP® 준수 또는 동등)
-
우리가 함께 코퍼스를 설계 — 도메인 선택, 난이도 분포, 진단 테스트, 타임라인, 예산.
-
작업 시작. 우리는 매주 점검해요. 학과는 언어학적 결정에 대한 완전한 자율성을 가지며, 우리는 모든 엔지니어링을 처리해요.
8. 자주 묻는 질문
"이미 병렬 코퍼스가 있어요. 사용할 수 있나요?"
네 — 코퍼스에 명확한 출처가 있고, 사람이 작성했으며, 라이선스가 평가에서의 사용을 허용한다면요. 우리가 그것을 우리 스키마에 맞게 포맷하고, 누락된 메타데이터를 추가하고, 통합하도록 도와드려요. 기존 코퍼스는 타임라인을 극적으로 가속화할 수 있어요(2단계를 건너뛰거나 공백 채우기 작업으로 축소).
"우리 언어에는 FST가 없어요."
괜찮아요. LYSS-fst(형태론적 유효성)는 FST를 필요로 하지만, 하니스는 그것 없이도 Profile B 가중치(chrF++, BLEU, COMET, 행동 메트릭)를 사용해 작동해요. 관련 언어에 대한 GiellaLT FST가 존재한다면, 우리가 그것을 각색할 수 있을지도 몰라요. 그렇지 않더라도, 코퍼스는 여전히 가치 있는 평가를 가능하게 해요 — 단지 형태론적 유효성 게이트가 없을 뿐이에요.
"우리 화자들은 비라틴 문자를 사용해요."
완전히 지원돼요. 코퍼스 스키마는 모든 유니코드 문자를 처리해요. 우리는 Cree를 위해 SRO(Standard Roman Orthography)와 음절문자를 위해 설계했지만, 동일한 인프라가 데바나가리, 아랍 문자, CJK, 에티오피아 문자, 또는 그 밖의 모든 문자 체계에 작동해요.
"방언 변이는 어떻게 되나요?"
태그를 다세요. 코퍼스 항목 스키마는 방언 정보를 위한 notes 필드를 포함해요. 여러 방언이 표현되는 경우, 그것들을 문서화하세요. 린터의 등가 클래스(LYSS-eq)는 방언 변형을 등가로 받아들이도록 구성할 수 있어요. 진단 테스트 스위트는 방언별 대조를 포함할 수 있어요.
"코퍼스는 누가 소유하나요?"
거버넌스 조직을 통해 언어 커뮤니티가 소유해요. 학과는 연구 파트너로 명시돼요. Champollion은 운영 연속성을 위해 에스크로 키 분할을 보유하지만 단독으로 봉인된 데이터에 접근할 수 없어요. development 세그먼트는 커뮤니티가 지정한 Creative Commons 라이선스 하에 게시돼요.
"중단하고 싶으면 어떻게 되나요?"
커뮤니티는 암호화 키 재구성을 거부함으로써 언제든지 평가 접근을 철회할 수 있어요. 봉인된 데이터는 결코 노출되지 않아요. 이미 게시된 development 세그먼트는 해당 라이선스 하에 공개로 유지돼요. 학과의 연구 산출물(출판물, 발표)은 어떤 경우에도 학과의 것이에요.
"거버넌스 조직이 아직 존재하지 않으면 어떻게 되나요?"
우리는 거버넌스 조직 없이도 1~3단계(코퍼스 설계, 생성, 품질 보증)를 시작할 수 있어요. 봉인(4단계)은 키 관리자 식별을 필요로 해요. 그동안 학과가 Champollion 프로젝트와 함께 공동 관리자 역할을 할 수 있으며, 커뮤니티 거버넌스 조직이 설립되면 관리 권한이 그곳으로 이전된다는 양해 하에서요.
부록: 태깅 vs. 코퍼스 구축
이 문서는 코퍼스 구축 — 평가 그라운드 트루스를 형성하는 병렬 텍스트 쌍을 만드는 것 — 을 다뤄요. 태깅(형태론적 주석, 행간 주석, FST 태그 문자열)은 코퍼스를 풍부하게 하지만 기본 평가에는 필요하지 않은 별도의 활동이에요.
| 활동 | 필수인가? | 무엇을 가능하게 하는가 |
|---|---|---|
| 코퍼스 구축(이 문서) | ✅ 필수 | 기본 평가: chrF++, exact match, COMET, 행동 메트릭 |
| FST 커버리지 검사 | 🟡 선택 | LYSS-fst 형태론적 유효성 메트릭 |
| 형태론적 주석 | 🟡 선택 | morphological_accuracy 메트릭(Scoring Spec §2.2) |
| 린터 등가 규칙 | 🟡 선택 | LYSS-eq 등가 일치 메트릭 |
| 의미 검증기 규칙 | 🟡 선택 | LYSS-sem 의미 검증 메트릭 |
| 화자 품질 평가 | 별도 활동 | 메트릭 검증(see Speaker Validation Protocol) |
태깅과 화자 검증은 별도의 문서에서 다루며, 코퍼스 구축과 병행하거나 그 이후에 진행할 수 있어요.