본문으로 건너뛰기

오류 신고와 수정에 대한 책임

입장. 수천 개의 언어에 관한 사실과 평가를 게시하는 플랫폼에서 틀리는 일은 불가피해요. 하지만 불가피하지 않은 것은 오류가 신고되었을 때 누가 신뢰받느냐, 그리고 누가 수정에 책임을 지느냐예요. 우리의 답은 이래요. 유창한 화자의 신고는 우리의 자동화보다 우선하고, 모든 수정에는 누가 무엇을 왜 바꿨는지를 밝히는 출처가 따르며, 커뮤니티는 자기 언어 데이터의 사용을 철회하거나 거부할 수 있어요 — 이는 호의가 아니라 아키텍처에 강제되는 속성으로서예요.

대부분의 데이터 플랫폼은 오류 신고를 지원 티켓처럼 취급해요. 사용자가 불만을 제기하면, 관리자가 결정하고, 레코드가 조용히 바뀌죠. 원주민 언어 데이터에서는 그 모델이 거꾸로예요. 오류를 신고하는 사람은 보통 플랫폼보다 더 권위가 있어요 — 어떤 단어가 틀렸다고 알려주는 화자는 "사용자"가 아니라, 대리 지표를 바로잡는 실측 자료(ground truth)예요. 아래의 설계는 이를 진지하게 받아들인 데서 나온 거예요.

두 종류의 오류, 하나의 원칙​

플랫폼은 틀릴 수 있는 두 종류의 주장을 게시해요.

  1. 언어에 관한 사실 — 평가를 구동하는 언어 카드. 분류 데이터, 정서법, 언어적 특징, 어떤 지표가 적용되는지가 여기에 해당해요. 어떤 카드는 잘못된 화자 추정치, 잘못된 방언 관계, 잘못된 문자 체계 상태를 주장할 수도 있어요.
  2. 번역에 관한 판단 — 화자가 틀렸거나 부자연스럽다고 여기는 코퍼스 내 참조 번역, 유효한 단어를 거부하거나 무효한 단어를 받아들이는 자동 지표, 화자가 받아들이지 않을 출력물에 붙은 "Deployable" 배지 등이에요.

둘 다를 포괄하는 원칙은 채점 명세와 벤치마크 명세 §7에서 이미 구속력을 가져요. 자동화된 출력물은 대리 지표이고, 화자가 실측 자료예요. 화자 검증 프로토콜 §6에 게시된 약속은 이를 단도직입적으로 말해요. 화자가 린터가 무언가에 대해 틀렸다고 하면, 우리는 린터를 고쳐요.

신고가 거치는 경로​

신고가 거치는 경로를 솔직한 상태 표시와 함께 정리했어요 — 일부는 오늘 운영 중이고, 일부는 명세화되었지만 아직 구축되지 않았어요.

잘못된 번역이나 지표 판단 신고하기(현재 직접 채널로 운영 중). 잘못된 참조 번역, 잘못 거부된 단어, 받아들일 수 없는 "동등 표현"을 발견한 화자는 프로젝트의 공개 저장소 이슈 트래커를 통해 신고하거나 프로젝트에 직접 연락할 수 있어요. 이것의 구조화된 버전 — reject / gist / acceptable / excellent 옵션이 있는 평가 화면과 자유 형식 메모 — 은 커뮤니티 리뷰 인터페이스이며, 벤치마크 명세 §7.3에 명세화되어 있지만 아직 가동되지는 않았어요. 그때까지 신고는 사람 대 사람으로 처리되며, 검증 작업 자체(유료, 구조화된 화자 리뷰 — 화자가 보수를 받는 방식 참고)가 주요 수정 파이프라인이에요.

언어 카드의 잘못된 사실 신고하기(현재 같은 채널로 운영 중). 카드 수정은 동일한 경로를 따라요. 신고, 리뷰, 버전 관리된 변경이죠. 카드는 평가 동작 — 어떤 지표가 로드되고 어떤 모델이 권장되는지 — 을 구동하기 때문에, 카드 수정은 점수를 바꿀 수 있어요. 따라서 수정은 기록된 데이터 변경으로 적용되며, 조용한 편집은 절대 하지 않아요.

다음에 일어나는 일 — 누가 결정하느냐:

  • 언어적 판단은 해당 언어의 화자에게 속해요. 어떤 형태가 유효한지, 두 표현이 동등한지, 어떤 어체가 적절한지 — 플랫폼은 그 답을 구현할 뿐, 답을 제공하지 않아요. 화자들이 의견이 갈리는 경우(방언, 정서법 관습), 그 답은 우리가 판정하는 것이 아니라 변이로 기록돼요 — 코퍼스와 린터 스키마는 방언 변이형을 하나의 승자를 강요하는 대신 허용 가능한 대안으로 태깅하는 것을 지원해요.
  • 커뮤니티 데이터에 관한 결정은 그 거버넌스 조직에 속해요. 거버넌스 조직이 있는 언어의 경우, 평가 코퍼스 변경, 봉인된 테스트 세트에 수정 사항을 반영하는 일, 배포 결과는 그들을 거쳐요 — 이것이 OCAP®의 통제(Control) 원칙을 포스터가 아니라 프로세스로 구현한 거예요.
  • 기계적 오류는 그냥 고쳐요. 오타, 깨진 링크, 잘못 파싱된 필드 — 신고하고, 수정하고, 로그에 남겨요. 모든 일에 위원회가 필요한 것은 아니에요.

수정에는 출처가 따라요​

추적할 수 없는 수정은 그저 더 새로운 의견일 뿐이에요. 모든 사실과 모든 수정에는 세 가지 출처 규칙이 적용돼요.

  1. 모든 사실은 그 출처를 명시해요. 언어 카드와 코퍼스 항목은 각 값이 어디서 왔는지 기록해요 — 게시된 데이터셋, 커뮤니티 기여, 화자의 리뷰 등이에요.
  2. 파생된 값은 상위 출처의 것이 아니라 우리의 것으로 표시돼요. 플랫폼이 무언가를 계산할 때 — 집계, 재코딩, 합성값(composite) — 이는 상위 출처의 이름으로 작성되는 것이 아니라, 상위 출처로부터의 플랫폼 파생물로 기록돼요. 상위 데이터셋이 게시하지 않은 수치에 대해 비난받거나 공로를 인정받아서는 안 돼요.
  3. 수정은 기록의 일부가 돼요. 화자의 수정은 기존 값을 대체하는 새로운, 출처가 표시된 주장(화자의 선택에 따라 실명 또는 익명 — 검증 작업과 동일한 조건)으로 기록되며, 무엇이 바뀌었는지의 이력은 감사 가능하게 남아요. 코퍼스 버전은 해시 매니페스트로 관리되므로(코퍼스 파트너십 §4.4), 수정된 코퍼스는 눈에 띄는 새 버전이 되고, 모든 실행 카드(run card)는 어떤 버전에 대해 채점되었는지를 정확히 기록해요 — 기존 점수는 해석 가능하게 유지되고, 새 점수는 수정 사항을 반영해요.

거부권, 구체적으로​

"커뮤니티 통제"라고 주장하기는 쉬워요. 게시된 아키텍처에서 그것이 실제로 무엇을 의미하는지 알려드릴게요.

  • 화자는 자신의 기여를 철회할 수 있어요. 화자는 언제든 자신의 평가를 거둘 수 있고, 철회하면 모든 분석에서 제거돼요(화자 검증 §5). 화자는 또한 문제가 있다고 여기는 결과의 게시에 대해 거부권을 가져요.
  • 커뮤니티는 평가를 완전히 중단시킬 수 있어요. 봉인된 테스트 세트는 암호화되며, 플랫폼 단독으로는 결코 재구성할 수 없도록 키가 보관돼요. 커뮤니티는 키 재구성 참여를 거부함으로써 평가 접근을 철회할 수 있어요(코퍼스 파트너십 §4.3). "우리가 중단하고 싶으면 어떻게 하나요?"에는 명세화된 답이 있어요. 봉인된 데이터는 절대 노출되지 않고, 평가가 종료돼요.
  • 어떤 점수도 커뮤니티의 결정을 무효화하지 못해요. 리더보드 1위를 차지한 방법이라도 거버넌스 조직이 동의해야만 배포돼요(소유권 이전) — 그리고 자기 언어에 MT를 전혀 배포해서는 안 된다고 결정하는 커뮤니티는 시스템을 망가뜨리는 것이 아니라 설계된 대로 행사하는 거예요(번역은 부흥이 아니에요 참고).

아직 구축하지 않은 것​

이 섹션의 나머지와 같은 정신에서 말씀드려요. 커뮤니티 리뷰 인터페이스는 계획되어 있지만 가동 중은 아니에요. 거버넌스 조직은 현재 언어들 중 어느 것에 대해서도 아직 설립되지 않았어요 — Plains Cree 벤치마크에 대한 커뮤니티 관리권은 확인 중이며, 우리는 동의가 이루어지기 전에 관리자를 공개적으로 명시하지 않아요. 그 부분들이 존재하기 전까지 수정은 직접적이고 출처가 표시되는 채널을 거치며, 이 페이지가 아니라 게시된 명세가 프로세스에 대한 구속력 있는 설명으로 남아요. 이 페이지와 명세가 일치하지 않는 경우 명세가 우선하며, 우리는 그 불일치 역시 신고할 가치가 있는 버그로 여길 거예요.

이것이 당신에게 의미하는 것​

:::info 당신이 커뮤니티 구성원이라면 이 플랫폼에서 당신의 언어에 관한 무언가가 틀렸다면 — 사실이든, 번역이든, 라벨이든 — 당신의 신고는 분류되어야 할 불만이 아니라 실측 자료로부터의 증언이에요. 당신의 수정에 실명을 표기할지 여부는 당신이 결정해요. 당신의 기여는 나중에 철회할 수 있어요. 그리고 당신의 커뮤니티는 자기 데이터의 사용을 전면 중단시킬 수 있어요. 언어 커뮤니티를 위한 안내에서 시작하거나, 공개 저장소에 이슈를 열어보세요. :::

:::info 당신이 연구자라면 이곳의 수정은 조용한 편집이 아니라 출처가 있는 데이터예요. 코퍼스 버전은 해시되고, 실행 카드는 채점된 정확한 버전을 고정하며, 파생된 값은 파생물로 표시돼요. Arena 점수나 코퍼스를 기반으로 작업한다면 버전을 인용하세요 — 그리고 화자 주도의 수정 물결을 지표 타당성에 관한 발견으로 다루세요. 실제로 그것이 바로 그런 것이니까요. :::

:::info 당신이 빌더라면 당신의 방법의 점수는 코드가 바뀌지 않아도 정당하게 바뀔 수 있어요 — 잘못 거부된 단어가 허용 목록에 추가되고, 참조 번역이 수정되고, 변이형 클래스가 고쳐질 수 있죠. 그것을 염두에 두고 설계하세요. 실행 카드에 코퍼스 버전을 고정하고(실행 카드 명세), 데이터셋 변경 로그를 지켜보고, 화자 수정을 공짜로 얻을 수 있는 가장 신뢰할 만한 오류 신호로 여기세요. :::

함께 보기​