AI 시스템 평가의 어려움

서론

인공지능(AI)이 사회에 미치는 영향에 관한 논의는 대부분 AI 시스템의 특정 속성—진실성, 공정성, 오남용 가능성 등—을 중심으로 이루어집니다. 이런 논의가 가능한 이유는 해당 영역에서 모델의 성능을 기술적으로 평가할 수 있기 때문입니다. 그러나 AI 분야 안팎의 많은 사람이 충분히 인식하지 못하는 사실이 하나 있습니다. 바로 견고하고 신뢰할 수 있는 모델 평가를 구축하는 일이 얼마나 어려운지입니다. 현재 널리 사용되는 평가 체계 상당수는 모델의 역량이나 안전성을 정확하게 나타내는 지표로서 한계를 지닙니다.

Anthropic에서는 자사 AI 시스템을 더 깊이 이해하기 위해 평가 개발에 많은 시간을 투자하고 있습니다. 또한 책임 있는 확장 정책(Responsible Scaling Policy)에서 보듯, 조직 차원의 안전성을 높이기 위해서도 평가를 활용합니다. 이 과정에서 평가를 개발하고 실행하는 일이 얼마나 까다로운지 몸소 체감하게 되었습니다.

이 글에서는 자사 모델을 평가하며 직면한 다양한 과제를 정리하여, 실제로 모델 평가를 개발·구현·해석하는 과정이 어떤 모습인지 공유하고자 합니다. 평가에 기반한 AI 거버넌스 정책을 수립하는 분들, 그리고 AI 시스템 평가를 전문으로 하는 조직을 운영하거나 확장하려는 분들에게 유용한 참고 자료가 되기를 바랍니다. 이 글의 핵심 메시지는 두 가지입니다. 첫째, 견고한 평가를 개발하고 구현하기란 극도로 어렵다는 것. 둘째, 효과적인 AI 거버넌스는 AI 시스템을 실질적으로 평가할 수 있는 능력에 달려 있다는 것입니다.

이 글에서는 AI 평가를 개발하며 겪은 과제들을 난이도가 낮은 것부터 높은 것 순서로 다룹니다:

1. 객관식 평가
2. BIG-bench, HELM 등 서드파티 평가 프레임워크
3. 크라우드워커를 활용한 모델의 유용성·유해성 측정
4. 도메인 전문가를 활용한 국가 안보 관련 위협 레드팀 평가
5. 생성형 AI를 활용한 생성형 AI 평가 개발
6. 비영리 조직과의 협업을 통한 위험 역량 감사

마지막으로, 이러한 과제를 해결하기 위한 몇 가지 정책 제언으로 글을 마무리합니다.

과제

단순해 보이는 객관식 평가

객관식 평가는 표준화 시험과 유사하게, 정확도(accuracy)라는 단일 지표로 다양한 과제에서의 모델 성능을 정량화합니다. 여기서는 언어 모델용 객관식 평가로 널리 사용되는 MMLU(Measuring Multitask Language Understanding)와 BBQ(Bias Benchmark for Question Answering) 두 가지에서 발견한 문제점을 살펴봅니다.

MMLU: 정말 측정하려는 것을 측정하고 있을까?

MMLU(Massive Multitask Language Understanding) 벤치마크는 수학, 역사, 법학 등 57개 과제에 대한 정확도를 측정합니다. 전문 지식이 필요한 다양한 과제를 하나의 정확도 점수로 나타낼 수 있어 널리 사용되며, 점수가 높을수록 더 뛰어난 모델로 간주됩니다.

MMLU에서 발견한 네 가지 문제점은 사소해 보이지만 중요하며, 다른 객관식 평가에도 해당됩니다:

1. MMLU가 워낙 널리 사용되다 보니, 모델이 학습 과정에서 MMLU 문제를 접할 가능성이 높습니다. 시험 전에 문제를 미리 보는 것과 다름없으므로 사실상 부정행위에 해당합니다.
2. 선택지를 (A)에서 (1)로 바꾸거나, 괄호를 (A)에서 [A]로 변경하거나, 선택지와 답변 사이에 공백을 하나 추가하는 등 단순한 형식 변경만으로도 정확도가 약 5% 변동할 수 있습니다.
3. AI 개발사마다 MMLU를 구현하는 방식이 다릅니다. 퓨샷 학습(few-shot learning)이나 사고 연쇄(chain-of-thought) 추론처럼 점수를 끌어올리는 것으로 알려진 기법을 사용하는 연구소도 있습니다. 따라서 연구소 간 MMLU 점수를 비교할 때는 각별한 주의가 필요합니다.
4. MMLU는 꼼꼼한 검수를 거치지 않았을 가능성이 있습니다. 실제로 라벨이 잘못 부여되었거나 답을 구할 수 없는 문제가 발견되었습니다.

이처럼 (겉보기에) 단순하고 표준화된 평가를 실행하는 데도 까다로운 판단과 세심한 고려가 필요하다는 것이 우리의 경험입니다. MMLU에서 겪은 이런 문제들은 유사한 객관식 평가 전반에도 적용됩니다.

BBQ: 사회적 편향 측정은 더 어렵다

객관식 평가로 모델이 부정적 고정관념에 의존하고 이를 확산하는 경향, 즉 유해성도 측정할 수 있습니다. 우리는 자사 모델(Claude)에서 이러한 유해성을 측정하기 위해 BBQ(Bias Benchmark for QA)를 사용합니다. BBQ는 9개 사회적 차원에 걸쳐 보호 대상 집단에 대한 사회적 편향을 테스트하는 평가입니다. BBQ가 사회적 편향을 제대로 측정한다는 확신은 실제로 구현한 뒤 유사한 여러 평가와 비교하고 나서야 갖게 되었으며, 이 과정에만 수개월이 소요되었습니다.

BBQ 구현은 예상보다 훨씬 어려웠습니다. MMLU처럼 바로 가져다 쓸 수 있는 오픈소스 구현체를 찾을 수 없었고, 결국 팀 내 역량이 뛰어난 정규 엔지니어 한 명이 온전히 일주일을 투입해야 구현과 테스트를 마칠 수 있었습니다. 벤치마크 개발1과 구현에서 복잡도를 높이는 핵심 요인은 BBQ의 '편향 점수(bias score)'입니다. 정확도와 달리, 편향 점수는 정의·계산·해석 모두에 뉘앙스와 경험이 필요합니다.

BBQ는 편향을 -1에서 1 사이로 측정합니다. 1은 심각한 고정관념적 편향, 0은 편향 없음, -1은 심각한 반고정관념적 편향을 의미합니다. BBQ를 구현한 결과, 일부 모델의 편향 점수가 0으로 나와서 편향 있는 출력을 줄이는 데 진전이 있다고 기대했습니다. 이 결과를 내부에 공유했을 때, Anthropic에서 근무 중인 BBQ 주요 개발자가 모델이 실제로 질문에 답하고 있는지 간단한 검증을 해보았느냐고 물었습니다. 확인해 보니 모델이 답변 자체를 하지 않고 있었습니다. 기술적으로는 편향이 없는 결과였지만, 완전히 무의미한 데이터였던 것입니다. 정량적 점수를 과잉 해석하여 실제로는 진전이 없는데 진전이 있다고 착각하는 실패 모드는 모든 평가에 존재합니다.

서드파티 평가 프레임워크, 만능은 아니다

최근 서드파티에서 다양한 모델에 적용할 수 있는 평가 모음을 활발히 개발하고 있습니다. 지금까지 우리는 BIG-bench와 Stanford의 HELM(Holistic Evaluation of Language Models) 두 가지에 참여했습니다. 서드파티 평가는 직관적으로는 매우 유용해 보입니다—이상적으로는 독립적이고, 중립적이며, 공개되어 있으니까요. 하지만 두 프로젝트 모두 새로운 과제를 드러냈습니다.

BIG-bench: 다양한 평가를 모으는 상향식 접근

BIG-bench는 450명 이상의 저자가 기여한 204개 평가로 구성되며, 과학부터 사회적 추론까지 폭넓은 주제를 다룹니다. 이 프레임워크를 사용하면서 겪은 주요 과제는 다음과 같습니다:

1. BIG-bench를 시스템에 설치하는 것만으로도 상당한 엔지니어링 작업이 필요했습니다. MMLU처럼 바로 사용할 수 있는 형태가 아니었고, BBQ보다도 더 많은 노력이 들었습니다.
   
2. BIG-bench는 효율적으로 확장되지 않았습니다. 합리적인 시간 내에 204개 평가를 모두 실행하기가 어려웠고, 속도를 높이려면 우리 인프라에 맞게 코드를 대폭 재작성해야 하는 대규모 엔지니어링 작업이 필요했습니다.
3. 구현 과정에서 일부 평가에 버그를 발견했는데, 특히 BBQ의 변형인 BBQ-lite 구현에서 문제가 두드러졌습니다. 이 버그를 발견한 후에야 BBQ를 직접 구현하는 데 더 많은 시간과 노력을 투입해야 한다는 사실을 깨달았습니다.
4. 어떤 과제가 가장 중요하고 대표성이 있는지 판단하려면 204개 과제를 모두 실행하고, 결과를 검증하고, 출력을 심층 분석해야 합니다. 이는 상당한 엔지니어링 역량을 갖춘 조직에서도 만만치 않은 연구 과제입니다.2

BIG-bench 구현 시도 자체는 유익한 경험이었지만, 실용성이 떨어진다고 판단하여 이 실험 이후 사용을 중단했습니다.

HELM: 전문가 주도의 하향식 평가 큐레이션

BIG-bench가 누구나 과제를 제출할 수 있는 '상향식' 방식이라면, HELM은 전문가가 평가할 과제를 직접 선정하는 '하향식' 방식을 취합니다. HELM은 추론, 허위 정보 등의 시나리오에서 정확도, 보정(calibration), 견고성, 공정성 같은 표준화된 지표로 모델을 평가합니다. 우리는 HELM 개발팀에 API 접근 권한을 제공하여 벤치마크를 실행하도록 합니다. 이 방식은 BIG-bench에서 겪었던 두 가지 문제를 해결합니다. 1) 우리 측에서 큰 엔지니어링 노력이 필요 없고, 2) 전문가가 선별한 고품질 평가의 선정과 해석을 신뢰할 수 있다는 점입니다.

그러나 HELM에도 고유한 과제가 있습니다. 다른 제공사의 모델을 평가할 때 잘 작동하는 방법이 우리 모델에는 맞지 않을 수 있고, 그 반대도 마찬가지입니다. 예를 들어, Anthropic의 Claude 시리즈 모델은 Human/Assistant라는 특정 텍스트 형식을 따르도록 학습되어 있습니다. 내부 평가 시에는 이 형식을 준수하는데, 형식을 지키지 않으면 Claude가 비정상적인 응답을 하여 표준화된 평가 지표의 신뢰성이 떨어집니다. HELM은 다른 모델과의 프롬프트 일관성을 유지해야 하므로 우리 모델 평가 시 Human/Assistant 형식을 사용하지 않습니다. 결과적으로 HELM은 Claude의 실제 성능을 왜곡된 형태로 보여주게 됩니다.

또한 HELM의 반복 주기가 느려서 신규 모델 평가에 수개월이 소요될 수 있습니다. 연구 대학이 주도하는 자원봉사 기반의 엔지니어링 프로젝트라는 점을 고려하면 이해할 수 있지만, 빠르게 진화하는 모델을 이해하려면 더 빠른 피드백이 필요합니다. 마지막으로, HELM은 외부 당사자와의 조율과 소통을 수반합니다. 양측 모두 인력이 부족하고 다른 업무에도 쫓기는 상황이라 시간과 인내가 필요하며, 이 역시 긴 반복 주기의 원인이 됩니다.

인간 평가의 주관성

지금까지는 단순한 객관식 시험과 유사한 평가만 다루었지만, AI 시스템은 사람과의 개방적이고 역동적인 상호작용을 위해 설계됩니다. 실제 사용 환경에 더 가까운 평가는 어떻게 설계할 수 있을까요?

크라우드워커를 활용한 A/B 테스트

현재 우리가 주로(전부는 아니지만) 의존하는 인간 평가 방식은 다음과 같습니다. 크라우드소싱 또는 계약 플랫폼에서 A/B 테스트를 실시하여, 참여자가 두 모델과 자유롭게 대화한 후 모델 A 또는 B 중 더 유용하거나 무해한 응답을 선택합니다. 무해성 평가의 경우, 크라우드워커가 모델을 적극적으로 레드팀하도록, 즉 유해한 출력을 유도하도록 권장합니다. 이렇게 수집된 데이터로 모델의 유용성·무해성 순위를 매깁니다. 이 접근법은 실제적인 환경(객관식 시험이 아닌 대화)에 부합하고, 서로 다른 모델을 상대 비교할 수 있다는 장점이 있습니다.

그러나 이 평가 방식에는 몇 가지 한계가 있습니다:

1. 실험에 비용과 시간이 많이 듭니다. 서드파티 크라우드워커 플랫폼이나 계약업체와 협력하고 비용을 지불해야 하며, 모델 전용 웹 인터페이스를 구축하고, A/B 테스터를 위한 상세한 지침을 설계하고, 수집된 데이터를 분석·저장하고, 크라우드워커 고용에 수반되는 여러 윤리적 문제에도 대응해야 합니다. 무해성 테스트의 경우, 참여자가 유해한 출력에 노출되는 위험까지 추가됩니다.
2. 인간 평가는 평가자의 특성에 따라 결과가 크게 달라질 수 있습니다. 평가자의 창의성, 동기 수준, 시스템의 잠재적 결함이나 문제를 파악하는 능력 등이 평가 결과에 영향을 미치는 주요 요인입니다.
3. 유용성과 무해성 사이에는 본질적인 긴장 관계가 있습니다. "죄송합니다, 도와드릴 수 없습니다"처럼 무용한 응답만 하면 유해성을 쉽게 피할 수 있습니다. 유용성과 무해성의 적절한 균형점은 어디일까요? 모델이 충분히 유용하면서 무해하다고 판단할 수치 기준은 무엇일까요? 유용성과 무해성을 넘어 어떤 상위 수준의 규범과 가치를 테스트해야 할까요?

인간 평가의 과학을 발전시키기 위한 추가 연구가 필요합니다.

국가 안보 관련 유해성 레드팀 평가

크라우드워커를 넘어, 국가 안보와 관련된 영역에서 도메인 전문가가 모델의 유해한 출력을 레드팀 방식으로 평가하는 방법도 탐구해 왔습니다. 목표는 AI 모델이 국가 안보 위험을 야기하거나 악화시킬 수 있는지, 있다면 어떤 방식인지를 파악하는 것입니다. 최근에는 이러한 위험에 대한 더 체계적인 레드팀 접근법을 시범 운영했으며, 이를 프런티어 위협 레드팀(frontier threats red teaming)이라 부릅니다.

프런티어 위협 레드팀은 주제 전문가와 함께 우선순위가 높은 위협 모델을 정의하고, 전문가가 모델을 집중적으로 탐색하여 사전 정의된 위협 모델에 따라 시스템이 국가 안보 위험을 야기하거나 악화시킬 수 있는지 평가한 뒤, 반복 가능한 정량적 평가와 완화 방안을 개발하는 과정으로 구성됩니다.

프런티어 위협 레드팀 초기 작업에서 추가적인 과제도 발견되었습니다:

1. 국가 안보라는 맥락의 고유한 특성 때문에 다른 유형의 유해성 평가보다 어려움이 큽니다. 국가 안보 위험은 복잡하고, 전문적이면서 민감한 지식이 필요하며, 행위자가 실제로 피해를 일으킬 수 있는 현실 세계 시나리오에 기반합니다.
2. AI 시스템 레드팀은 현재 과학보다는 예술에 가깝습니다. 레드팀 담당자가 모델을 탐색하며 우려스러운 행동을 유도하지만, 이 과정은 아직 표준화되지 않았습니다. 레드팀이 모델 역량을 정확히 반영하고, 서로 다른 모델을 의미 있게 비교할 수 있는 공유 기준선을 마련하려면 견고하고 반복 가능한 프로세스가 필수적입니다.
3. 특정 사안에서는 다루는 정보의 성격상 보안 인가를 받은 레드팀 담당자의 참여가 필수적이라는 점도 확인했습니다. 그러나 이 경우 레드팀이 기밀 환경 밖에서 AI 개발자와 공유할 수 있는 정보가 제한될 수 있습니다. 이는 AI 개발자가 도메인 전문가가 식별한 위협을 충분히 이해하고 완화하는 능력을 제약할 수 있습니다.
4. 특정 국가 안보 유해성에 대한 레드팀 과정에서 모델이 통제 정보를 출력할 경우 법적 문제가 발생할 수 있습니다. 의도치 않은 법적 위험 없이 레드팀을 수행할 수 있도록 적절한 법적 면책 조항(safe harbor)을 마련하는 문제는 아직 미해결 과제입니다.

앞으로 국가 안보 관련 유해성 레드팀은 이해관계자 간 협력을 통해 표준화된 프로세스, 법적 안전장치, 민감한 정보를 보호하면서도 시스템을 테스트할 수 있는 안전한 정보 공유 프로토콜을 구축해야 합니다.

모델이 모델을 평가하는 우로보로스

모델이 인간 수준의 역량에 도달하기 시작하면서, 모델 자체를 활용한 자기 평가도 가능해졌습니다. 지금까지 모델을 활용해 새로운 객관식 평가를 생성하는 방식으로 다양한 문제 행동을 광범위하게 선별하는 데 성과를 거두었습니다. 이 접근법을 사용하면 인간이 개발할 때 수일에서 수개월이 걸리는 평가를 AI 시스템이 수 분 만에 만들어 냅니다.

그러나 모델 생성 평가에도 고유한 과제가 있습니다:

1. 현재 모델이 생성한 평가의 정확성은 인간이 검증합니다. 이는 앞서 설명한 인간 평가의 모든 과제를 그대로 이어받습니다.
2. BIG-bench, HELM, BBQ 등을 통해 확인했듯이, 우리 모델에는 사회적 편향이 존재하고 정보를 지어내는 경우도 있습니다. 따라서 모델이 생성한 평가 역시 이러한 바람직하지 않은 특성을 물려받을 수 있으며, 결과를 분리해내기 어려운 방식으로 왜곡할 수 있습니다.

반면 좋은 사례도 있습니다. Constitutional AI(CAI)는 인간 레드팀을 모델 기반 레드팀으로 대체하여 Claude가 더 무해해지도록 학습시키는 방법입니다. 모델이 모델을 레드팀하는 방식임에도, 놀랍게도 인간 평가자들은 사전에 인간이 레드팀한 모델보다 CAI 모델이 더 무해하다고 평가합니다. 이는 고무적이지만, 모델 생성 평가는 여전히 복잡하며 더 깊은 연구가 필요합니다.

서드파티 감사의 객관성을 유지하면서 내부 전문성 활용하기

서드파티 감사와 서드파티 평가의 차이점은, 감사는 위험에 초점을 맞춘 더 심층적인 독립 평가인 반면, 평가는 역량을 폭넓게 살핀다는 점입니다. 우리는 Alignment Research Center(ARC)가 수행하는 서드파티 안전 평가에 참여한 바 있습니다. ARC는 프런티어 AI 모델이 위험한 역량(자원 축적, 자기 복제, 종료 방해 등)을 보유하고 있는지 평가합니다. 외부 전문가를 활용하면 전문 도메인 지식을 활용하고 편향 없는 감사 가능성을 높일 수 있다는 장점이 있습니다. 처음에는 이 협업이 간단할 것으로 예상했지만, 실제로는 우리 측에서 상당한 과학·엔지니어링 지원이 필요했습니다. 전담 지원을 제공하느라 내부 평가 작업에 투입할 자원이 분산되었습니다.

이 감사를 진행하며 깨달은 것은, 감사자와 피감사자 간의 관계에는 신중하게 다뤄야 할 과제가 존재한다는 점입니다. 감사자는 평가의 무결성을 유지하기 위해 피감사자에게 세부 사항을 제한적으로 공유합니다. 하지만 충분한 정보 없이는 피감사자가 기술적 평가를 설계할 때 근본적인 문제에 대응하기 어려울 수 있습니다. 실제로 최종 감사 보고서를 확인한 뒤, ARC의 (기발하고 잘 설계된) 감사 접근법을 미리 더 자세히 알았더라면 우려되는 행동을 식별하는 데 더 도움이 될 수 있었을 것이라는 점을 깨달았습니다. 모델 역량의 한계 근처에서 성능을 끌어내는 것은 본질적으로 어려운 연구 과제이기 때문입니다. 프롬프트 엔지니어링과 언어 모델 파인튜닝은 활발한 연구 분야이며, 대부분의 전문성은 AI 기업 내부에 있습니다. 더 긴밀하게 협력했다면 우리 모델에 대한 깊은 기술적 지식을 활용하여 ARC가 평가를 더 효과적으로 수행할 수 있도록 도울 수 있었을 것입니다.

정책 제언

이 글에서 살펴보았듯이, 의미 있는 AI 평가를 구축하는 일은 만만치 않은 과제입니다. 평가의 과학과 공학을 발전시키기 위해 정책 입안자에게 다음을 제안합니다:

자금 지원 및 지원 대상:

• 반복 가능하고 유용한 평가의 과학. 어떤 조건이 평가를 유용하고 고품질로 만드는지에 대한 미해결 과제가 많습니다. 정부는 컴퓨터 과학 학과와 AI 평가 전문 기관을 대상으로 고품질 평가의 요건을 연구하고, AI 시스템의 비교 평가를 가능하게 하는 견고하고 재현 가능한 방법론을 개발하는 연구비 및 프로그램을 지원해야 합니다. 양보다 질에 투자할 것을 권합니다(저품질 평가 10개보다 고품질 평가 1개 개발에 자금을 지원하는 방식).
• 기존 평가의 구현. 새로운 평가를 계속 개발하는 것도 중요하지만, 이미 검증된 고품질 평가를 여러 당사자가 쉽게 구현할 수 있도록 지원하는 것 역시 중요합니다. 예를 들어, 정부가 BIG-bench 같은 평가를 손쉽게 설치·실행할 수 있는 소프트웨어 패키지 개발을 지원하거나, 버전 관리되고 표준화된 동적 벤치마크를 개발하여 구현 편의성을 높일 수 있습니다.
• 기존 평가의 견고성 분석. 평가가 구현된 이후에도 지속적인 모니터링이 필요합니다(예: 평가가 포화 상태에 도달하여 더 이상 유용하지 않은지 판단하는 것).

평가 전담 정부 기관에 대한 예산 확대. 미국의 국립표준기술연구소(NIST) 등이 대표적입니다. 또한 정책 입안자는 공개 'AI 안전 리더보드'를 통해 기업이 평가에서 좋은 성과를 내도록 행동 규범을 유도해야 합니다. 이는 NIST의 얼굴 인식 벤더 테스트(FRVT)와 유사한 방식으로 운영할 수 있습니다. FRVT는 상용 얼굴 인식 시스템에 대한 독립 평가를 제공하기 위해 만들어졌으며, 성능 벤치마크를 공개함으로써 소비자와 규제 기관이 다양한 시스템의 역량과 한계4를 더 잘 이해할 수 있게 했습니다.

기업이 정부 및 서드파티와 협력하여 국가 안보 위험에 대해 모델을 엄격히 평가할 수 있도록 법적 면책 조항(safe harbor) 마련—화학·생물·방사능·핵(CBRN) 방어 분야 등—법적 불이익 없이 안전성 향상에 기여할 수 있도록 해야 합니다. 여기에는 연구소가 식별된 위험에 대한 민감한 정보를 공유할 수 있는 '책임 있는 공개 프로토콜(responsible disclosure protocol)'도 포함될 수 있습니다.

결론

자사 시스템을 다양한 차원에서 평가하며 얻은 경험을 공개적으로 공유함으로써, AI 정책에 관심 있는 분들이 현재 모델 평가의 과제를 인식하는 데 도움이 되기를 바랍니다.

이 글이 도움이 되었고 Anthropic과 AI 시스템 평가에 대해 논의하고 싶으시다면 [email protected]으로 연락해 주세요. 앞으로 몇 개월간 더 많은 분들과 이 주제로 대화를 나눌 예정이며, 그 과정에서 배운 내용을 공유하도록 하겠습니다.

이 글을 인용하려면 아래 Bibtex 키를 사용하세요:

@online{ganguli2023challenges,
author = {Deep Ganguli and Nicholas Schiefer and Marina Favaro and Jack Clark},
title = {Challenges in evaluating {AI} systems},
date = {2023-10-04},
year = {2023},
url = {https://www.anthropic.com/index/evaluating-ai-systems},
}

각주

[1] BBQ 개발에는 얼마나 걸렸을까? BBQ는 8명이 6개월에 걸쳐 약 2인년(person-years)을 투입해 만들었습니다. 단일 평가 하나를 설계하고 구현하는 것만으로도 수십 명이 수개월간 매달려야 하는 자원 집약적 작업입니다.

[2] BIG-bench 출시 4개월 후 23개 난이도 높은 과제로 범위를 좁힌 BIG-bench Hard가 공개되었습니다. 우리는 BIG-bench Hard가 나오기 전에 BIG-bench를 구현하고 있었습니다.

[3] 예시로 Ghost Work를 참고하세요.

[4] 예를 들어, 많은 얼굴 인식 시스템에서 여성이나 유색 인종 등 특정 인구통계 집단에 대해 오류율이 높다는 것은 잘 알려진 문제입니다. FRVT 보고서는 이러한 정확도 격차를 조명하여, 벤더들이 알고리즘을 개선하고 체계적 편향을 완화하도록 압박하는 계기가 되었습니다.