데이터를 깊이 파고들기 | YC Paper Club

URL: https://www.youtube.com/watch?v=IfoPg2QefF8 날짜: 2026-08-21 채널: Y Combinator

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==데이터는 더 이상 값싼 상품(commodity)이 아니라, 모델의 실제 능력을 결정하는 가장 중요한 병목이자 전문성이 들어간 제품이다.== 모델 아키텍처와 GPU가 좋아져도 운영 환경의 분포 변화, 주관적 품질 판단, 에이전트의 긴 행동 궤적, 언어별 데이터 부족을 다루는 데이터가 없으면 인간 수준의 성능에 도달할 수 없다.

• 프랑수아 샤우바드(Francois Chaubard)는 Focal Systems의 현장 경험과 시장 변화를 통해 데이터가 아키텍처보다 중요한 이유를 설명한다.
• 빈센트 선 첸(Vincent Sunn Chen)은 전문가의 판단을 확장하는 데이터 프로그래밍과 시니어 에이전트를 평가하는 벤치마크 설계를 제시한다.
• 볼로 쿨레쇼프(Volo Kuleshov)는 확산 언어 모델의 초고속 추론도 현실적인 RL 환경과 데이터가 있어야 실제 제품 성능으로 이어진다고 말한다.
• 셰인 롱프리(Shayne Longpre)는 다국어 사전학습에서 언어 간 시너지와 간섭을 측정해 데이터 혼합·모델 크기·학습 전략을 결정하는 방법을 소개한다.

네 발표는 데이터의 역할을 단순한 학습 샘플 수에서 전문가가 설계한 환경, 검증 가능한 보상, 문화·언어별 분포, 데이터 출처 간 상호작용까지 확장한다. 좋은 데이터는 파일 묶음이 아니라 지속적으로 설계·검증·갱신되는 연구·제품 시스템이다.

1. 프랑수아 샤우바드 — 왜 데이터에 별도의 밤을 할애하는가

1.1. 데이터가 상품에서 전략적 병목으로 바뀐 배경

1. 2016년의 데이터 인식

   1. 프랑수아는 2016년에 박사과정을 그만두고 Focal Systems를 시작했다.
   2. 당시 업계의 지배적인 생각은 데이터가 이미 ImageNet 같은 공개 데이터셋으로 충분히 확보된 상품이라는 것이었다.
   3. “ImageNet을 이미 내려받았는데 데이터가 얼마나 더 필요하겠는가”라는 태도가 일반적이었다.

2. 시장의 판단이 뒤집힌 규모

   1. 당시에는 Scale AI가 10억 달러의 가치가 될 가능성이 없다는 말이 많았고, 대부분의 벤처캐피털리스트는 데이터 사업의 최종 가치(terminal value)를 0달러로 봤다.
   2. 프랑수아가 기억하기로 Scale의 시리즈 A에 투자한 사람은 Excel의 Levy 정도였고, 예외적인 투자자였다.
   3. 그 뒤 10년 동안 데이터 관련 기업이 만든 시가총액은 1,000억 달러를 넘었다.
   4. 데이터에 냉소적이던 VC 커뮤니티가 완전히 태도를 바꾼 이유는 데이터가 모델 성능을 좌우하는 실질적 생산 자산이라는 사실이 반복해서 드러났기 때문이다.

3. 오프닝의 농담과 분위기

   1. 진행자는 YC 데이터 클럽의 작은 그림에서 자신이 왕관을 쓰고 빈둥거리는 모습을 소개했다.
   2. 폴 그레이엄(Paul Graham)이 그 모습을 좋아하지 않았지만 이제는 자신의 이름을 안다는 점은 다행이라고 농담해 청중의 웃음을 유도했다.

1.2. 모델 성능을 올리는 첫 질문은 아키텍처가 아니라 데이터다

1. Focal Systems의 면접 질문

   1. 프랑수아는 Stanford나 MIT 출신 박사 지원자에게 “핫도그와 핫도그가 아닌 이미지를 분류하는 모델이 F1 점수 85%를 얻었다면 다음에 무엇을 하겠는가?”라고 물었다.
   2. 논문을 읽거나 ReLU와 GELU를 비교하거나 레이어를 더 쌓겠다는 답에는 “아니요, 다음”이라고 즉시 반응했다.
   3. 정답은 데이터셋을 다시 보고 모델이 어디서 틀리는지 파악하는 것이다.

2. 오류를 버킷으로 쪼개는 진단 절차

   1. 모든 거짓 양성(false positive)과 거짓 음성(false negative)을 모은다.
   2. 오류를 유형별 버킷으로 분류한 뒤 가장 큰 문제를 찾는다.
   3. Focal의 매장 재고 분류에서는 냉장고 유리에 낀 김 때문에 안을 볼 수 없는 경우, 사람이나 다른 물체가 앞을 가리는 경우, 화면에서 다른 일이 벌어지는 경우가 대표적인 오류였다.
   4. 사람이 가려서 재고 여부를 판별할 수 없는 상황은 레이어 수를 늘려도 해결되지 않는다. 문제의 원인이 아키텍처가 아니라 관측 가능한 데이터와 라벨의 한계이기 때문이다.

3. ImageNet과 인간 성능의 한계

   1. Andre는 ImageNet에서 인간 수준이 어느 정도인지 처음으로 측정하려고 직접 이미지를 하나씩 살펴보고 자신이 얼마나 정확히 분류할 수 있는지 확인했다.
   2. 사람은 생각보다 분류를 잘하지 못한다. 프랑수아는 Eskimo Sheepdog과 Siberian Husky를 구별하지 못한다고 자조했다.
   3. ImageNet의 약 30~40%가 개 또는 개 품종 이미지라는 사실도 언급됐다. 사람에게도 세부 품종 지식이 없으므로 데이터의 난도가 모델의 한계처럼 나타날 수 있다.
   4. 표현력이 충분히 큰 아키텍처에서는 학습 데이터의 구성과 품질이 아키텍처 자체보다 중요해진다.

4. 연구와 운영에서 시간 배분이 뒤집힌다

   1. 박사과정에서는 데이터에 약 5%, 아키텍처에 95%의 시간을 썼다.
   2. 생산 환경으로 가면 그 비율이 뒤집힌다. 발표자는 과거에는 25 대 75라고 말했지만 오늘날에는 데이터 3%, 아키텍처 97%에 가까워졌다고 표현했다.
   3. Transformer가 이미 매우 잘 작동하는 단계에 이르면서 남은 성능 개선의 중심이 데이터로 이동했다.

1.3. 예쁜 학습 분포와 처참한 운영 분포의 간극

1. ImageNet식 학습 데이터의 착시

   1. 학습 세트 안에서는 데이터가 정돈되어 있고 학습 분포(train distribution)가 아름답게 보인다.
   2. 모델을 운영 환경에 배포하면 학습 때 보지 못한 점들이 테스트·운영 분포에 갑자기 나타난다.
   3. 프랑수아는 이 순간 모델이 “스스로 토해내고(pukes itself)” 작동하지 않는다고 과장된 표현으로 청중에게 손을 들어본 경험이 있는지 물었다.

2. 현실 자동화를 위한 두 종류의 데이터

   1. 경제를 자동화하려면 전문가 데이터(expert data)와 전문가 RL 환경(expert RL environments)이 모두 필요하다.
   2. RL 환경은 정답을 실행해 확인할 수 있는 검증 가능한 보상(verifiable reward)을 제공해야 한다.
   3. 디자인 선호, 사용성, 코드 스타일, 의료 판단, 법관의 판단처럼 정답 하나로 환원되지 않는 문제에는 선호 데이터(preference-style data)가 필요하다.
   4. 코드는 실행되더라도 스타일이 나쁘고 유지보수 불가능할 수 있으며, 같은 환자를 본 두 의사나 같은 사건을 본 두 판사가 서로 다른 답을 낼 수 있다. 이런 주관성 자체가 데이터 설계의 대상이다.

1.4. 데이터셋과 RL 환경은 압축 파일이 아니라 제품이다

1. 전문 데이터에 필요한 장인정신

   1. 데이터셋과 환경을 제품으로 봐야 한다. Arc Institute의 Greg가 만드는 게임형 환경에 들어가는 장인정신과 Prime Intellect가 빠르게 만들어낸 결과의 대비가 언급됐다.
   2. 완전하고 현실적이며 고품질인 데이터셋을 만드는 일은 매우 어렵다.
   3. Focal의 단순한 재고·품절 분류만 해도 온톨로지를 세밀하게 정의하는 데 많은 시간이 들었다.

2. ‘상품을 앞으로 미는 사람’ 사례

   1. 진열대에서 상품처럼 보이지만 실제로는 사람이 상품을 앞으로 밀고 있는 장면이 있다.
   2. 이를 별도의 클래스인 ‘상품을 미는 사람’으로 만들지, 실제 재고가 보이지 않으므로 품절로 분류할지 결정해야 한다.
   3. 전자를 택하면 클래스가 늘고, 후자를 택하면 상품과 품절이 비슷하게 보이는 혼동이 커진다.
   4. 이런 경계 사례를 정의·라벨링·검증하는 판단이 데이터 제품의 핵심이며, 단순한 ZIP 파일 복사로 해결되지 않는다.

3. Salesforce UI 변화 사례

   1. Salesforce를 자동화한다고 가정하면 사용자의 화면 기록과 스크린 캡처를 1,000억 시간 모았더라도 충분하지 않을 수 있다.
   2. Salesforce가 UI를 바꾸는 순간 기존 기록과 운영 화면의 분포가 달라진다.
   3. 아무리 많은 데이터를 보유해도 변화한 UI에 맞는 새 데이터가 필요하다.
   4. 데이터의 가치는 고정된 보유량이 아니라 현재 환경과 계속 맞물려 갱신되는 적합성에 있다.

1.5. 아키텍처·GPU보다 부족한 전문가 궤적과 병목

1. 현 시점의 가장 큰 병목

   1. Brendan Iribe가 Sequoia에서 발표한 슬라이드에 프랑수아가 동의한다고 말하며, 현재 병목은 아키텍처가 아니라고 강조했다.
   2. 병목은 GPU도, 전력(watts)도 아니라 현실의 전문가 판단이 담긴 데이터다.

2. S&P 500 예측의 냉소적 실험

   1. 프랑수아가 게시한 분석에 따르면 어떤 모델도 S&P의 다음 7일 수익률을 예측할 때 무작위보다 나은 성능을 내지 못했다.
   2. 동전을 던지는 것이 현재 생산 환경에서 쓸 수 있는 모든 AI 모델보다 나을 수 있다는 강한 표현으로 한계를 설명했다.
   3. Goldman Sachs 트레이더처럼 무작위보다 분명히 나은 전문가의 행동 궤적(trace)이 충분히 있다면 모델이 학습할 수 있지만, 그런 데이터는 확보되지 않았다.
   4. 회계사·의사·변호사·트레이더 등 각 도메인에서 인간 능력을 맞추거나 넘으려면 해당 전문가가 실제로 잘한 사례와 판단 과정을 수집해야 한다.

3. 데이터 사업의 시장적 의미

   1. 지난 10년 동안 VC가 이 문제를 외면한 와중에도 데이터 기업은 1,000억 달러 이상 시가총액을 만들었다.
   2. 프랑수아는 이 분야를 YC가 투자한 최고의 카테고리 중 하나로 평가했다.

1.6. ‘앱 스토어’ 비유로 보는 데이터 기업의 규모

1. LLM의 전문직 능력은 앱이 필요하다

   1. Apple이 배달, 차량 호출, 손전등, 길 안내를 제공하려면 각 기능을 담당하는 앱이 필요하다.
   2. LLM이 의사, 회계사, 변호사, 목수, 트레이더, 치료사처럼 행동하려면 각 직무에 맞는 데이터와 RL 환경이 필요하다.
   3. 최신의 정제된 데이터와 업무 환경이 없으면 LLM은 그 직업의 실제 일을 수행할 수 없다.
   4. 따라서 가능한 데이터 기업의 수는 휴대전화에 설치할 수 있는 앱의 수만큼 많을 수 있다.

2. 플랫폼이 모든 전문 서비스를 직접 만들 필요는 없다

   1. Apple 전용 Instacart와 Android 전용 Instacart를 따로 만들 이유가 없듯이, 하나의 전문 데이터 기업이 여러 기반 모델을 지원할 수 있다.
   2. Apple과 Android가 손전등처럼 단순한 기능은 직접 제공할 수 있지만, Instacart의 물류망 전체를 구축해 Instacart와 경쟁할 이유는 없다.
   3. Anthropic, OpenAI, Google, Apple이 모두 의료 데이터·HIPAA 처리·의사 네트워크·환자별 병렬 궤적·선호 라벨을 직접 구축하기보다, 의료 환경을 잘 만드는 전문 기업 하나를 활용하는 편이 합리적이다.
   4. 특정 환자에 대한 여러 치료 궤적을 만들고 의사가 어느 궤적을 선호하는지 기록하는 작업은 범용 모델 회사보다 도메인 전문 데이터 기업의 역할에 가깝다.

1.7. 발표자 소개와 행사 구성

1. 초청 발표자
   1. 병으로 참석하지 못한 May의 발표는 다음 행사에 넣으려고 한다고 소개됐다.
   2. Vincent Sunn Chen은 Hazy Research 출신이자 Snorkel 창립팀 멤버이며, Snorkel을 10억 달러 시가총액 규모 이상으로 성장시켰다.
   3. Volo Kuleshov는 Inception Labs 창업자, Cornell 교수, 뛰어난 서퍼로 소개됐다.
   4. Shayne Longpre는 MIT 박사과정을 막 마쳤고, 사전학습 연구와 Data Provenance Initiative를 이끌었으며 최근 Anthropic에 합류했다.

2. 빈센트 선 첸 — 전문가 감독을 확장하는 데이터와 에이전트 벤치마크

2.1. 핵심 논지: 전문가의 머릿속 사양을 데이터로 옮겨라

1. Snorkel의 연구 방향

   1. Vincent는 Snorkel의 창립팀 멤버이자 Frontier Lab 사업을 시작했고, 현재 벤치마크와 평가 연구를 이끈다.
   2. Snorkel은 Stanford AI Lab에서 시작해 10년 넘게 데이터 문제를 연구해 왔다.
   3. 핵심 논지는 의사·임상의·기자·소프트웨어 엔지니어처럼 ‘좋은 결과가 무엇인지’에 대한 사양(spec)을 머릿속에 가진 전문가에게 레버리지를 제공하는 일이 효과적인 데이터셋의 진짜 병목이라는 것이다.

2. 전문가 감독(expert supervision)의 변환 과정

   1. 원시 데이터, 지저분한 문서, 지식 코퍼스에서 출발한다.
   2. 전문가의 판단과 지식을 추출해 평가·학습에 쓸 수 있는 데이터로 변환한다.
   3. 데이터의 형태는 단순한 라벨에서 과제·루브릭·검증기·미세한 채점 메커니즘이 포함된 Docker 환경으로 진화했다.
   4. 단순한 세계 하나를 만드는 데도 사람이 한 자리 수 시간에서 세 자리 수 시간까지 개발해야 할 수 있다.

3. 전문가 수와 시간의 제한

   1. 복잡한 분야의 전문가는 세계에 많지 않다.
   2. 그들에게 하루에 쓸 수 있는 시간도 한정되어 있다.
   3. 전문가를 모든 샘플에 직접 투입하는 대신, 전문성이 반복 사용될 수 있도록 데이터·소프트웨어·검증 절차 안에 인코딩해야 한다.

2.2. 데이터 1.0의 수작업 라벨링이 부딪히는 벽

1. 샘플마다 비용이 선형으로 늘어난다

   1. 이미지 분류나 질의응답에 사람이 하나씩 라벨을 붙이면 데이터 포인트마다 새로운 인지 노력이 필요하다.
   2. 수작업 라벨링 비용은 샘플 수에 대해 O(n)으로 증가한다.
   3. 전문가 영역에서는 MRI 데이터나 전자의무기록(EHR)을 대량 구축해야 하므로 이 방식이 근본적으로 확장되지 않는다.

2. 노이즈와 중복 라벨링

   1. 사람의 라벨은 항상 정확하지 않으며, 같은 사양을 서로 다르게 해석할 수 있다.
   2. 노이즈를 줄이려면 동일 샘플에 여러 번 라벨을 붙이는 k×n 수준의 중복 작업이 필요하다.
   3. 사양·스키마가 바뀌면 처음부터 다시 작업해야 한다.

3. 출처와 판단 근거의 소실

   1. 수작업 라벨만 남기면 왜 그렇게 판단했는지, 어떤 규칙과 근거를 사용했는지 알 수 없다.
   2. 라벨의 provenance(출처·판단 과정)가 없으므로 감사(audit), 토론, 수정, 협업이 어렵다.
   3. 전문 영역이 더 좁아질수록 MD-PhD나 특정 세부 분야 심장 전문의처럼 희소한 전문가에게 부담이 집중된다.

2.3. 데이터 프로그래밍: 전문가 감독을 소프트웨어로 표현하기

1. 라벨링 함수를 통한 지식 추출

   1. Snorkel의 데이터 프로그래밍(data programming)은 전문가의 감독을 코드로 표현하는 접근이다.
   2. 스팸과 정상 메일을 나누는 이유를 휴리스틱 또는 라벨링 함수(labeling function)로 작성하면 사람의 머릿속 규칙이 재현 가능하고 확장 가능한 형식으로 바뀐다.
   3. 소프트웨어의 규모를 얻으므로 데이터를 프로그램으로 라벨링할 수 있다.
   4. 규칙을 리팩터링하고 사양 변화에 맞춰 수정할 수 있으며, 코드 자체를 감사하고 논의하며 공동 작업할 수 있다.

2. 약한 감독과 신호의 노이즈 제거

   1. 여러 라벨링 함수는 서로 겹치고, 부정확하며, 각각 완전한 정답(ground truth)이 아니다.
   2. Snorkel은 이런 약한 감독(weak supervision) 신호의 품질을 추론하는 이론과 방법을 도입했다.
   3. 초기 라벨링 함수가 덮는 영역을 넘어 더 넓은 분포로 일반화하려면 노이즈를 인식하는 최종 모델이 필요하다.

3. 정답 키 없이 학생들의 표를 해석하는 비유

   1. 서로 다른 실력을 가진 학생들이 있고, 선생님의 정답표는 없지만 각 학생의 투표만 있다고 가정한다.
   2. 첫 단계는 각 투표자의 정확도를 비지도 방식으로 추정하는 것이다.
   3. 둘째 단계는 각 투표 결과를 바탕으로 실제 정답일 확률을 계산하는 것으로, 베이즈(Bayes)식 추론이 들어간다.
   4. 셋째 단계는 노이즈 인식 모델을 학습해 라벨 모델의 범위를 확장하고 더 넓은 분포의 노이즈를 줄이는 것이다.

4. 데이터 1.0의 요약

   1. 초기 Snorkel 연구의 초점은 전문가의 라벨과 판단을 소프트웨어로 확장하는 것이었다.
   2. 가장 중요한 추가 문제는 정답 데이터가 없는 상황에서 서로 겹치는 약한 신호를 어떻게 정제할지였다.
   3. 이런 기법은 현재의 실제 생산 시스템에서도 여전히 사용된다.

2.4. 데이터 2.0: 에이전트가 복잡해질수록 평가 데이터도 복잡해진다

1. 복잡성의 두 축

   1. 입력 복잡성은 프롬프트와 사양이 얼마나 복잡한지, 출력 복잡성은 모델이 만들어야 하는 결과가 얼마나 복잡한지를 뜻한다.
   2. 환경 복잡성은 단순한 질의응답에서 데스크톱에 YOLO(무제한에 가까운) 접근 권한을 가진 에이전트 환경으로 이동하는 정도다.
   3. 세로축에는 에이전트가 실제로 얼마나 긴 순서(sequence length) 동안 작업하는지가 놓인다.
   4. 소프트웨어 영역에서 기본 평가가 포화된 것처럼 보여도, 터미널 기반 에이전트의 작업 길이와 책임 범위는 계속 커진다.

2. 기존 벤치마크의 포화와 새로운 난이도

   1. HumanEval 같은 기본 평가는 이미 포화됐지만, ProgramBench에서는 최신 모델이 이제 막 1%를 넘겼다고 설명했다.
   2. 에이전트의 복잡성과 책임이 커질수록 학습과 평가에 쓰는 데이터의 중요성도 커진다.
   3. 단순한 코드 정답보다 긴 궤적, 아키텍처 결정, 대규모 리팩터링을 평가할 수 있어야 한다.

3. Senior SWE-bench의 목적

   1. 실제 사용자는 코딩 에이전트를 주니어가 아니라 시니어 엔지니어처럼 믿고 아키텍처 결정을 맡기며 코드 전체를 리팩터링한다.
   2. 그런데 기존 평가는 에이전트를 주니어 엔지니어 수준의 단순 문제로 평가한다.
   3. Princeton의 원래 SWE-bench 팀과 협력해 시니어 엔지니어가 실제로 수행할 법한 작업을 대표하는 데이터셋과 벤치마크를 만들었다.
   4. 목표는 전문가 감독을 확장하면서도 실제 업무를 대표하는 고품질 평가를 만드는 것이었다.

2.5. 현실적인 작업 지시와 ‘취향 있는’ 보상 설계

1. 과도하게 상세한 지시를 버리기

   1. Harbor 평가 프레임워크를 사용해 자연어 지시가 포함된 작업을 만들었다.
   2. 전통적인 SWE-bench 샘플은 무엇을 하고 하지 말아야 하는지를 지나치게 세세하게 적은 EDD 수준의 지시가 많다.
   3. 실제 업무처럼 Slack 메시지, 로그 덤프, 사용자의 몇 가지 스토리만 주고 문제를 알아서 해결하게 했다.
   4. “이 아이디어를 구현해 달라”는 사용자 스토리처럼 더 높은 수준의 추상화를 넣는 일 자체가 매우 어려운 데이터 설계 작업이었다.

2. 정답·병합 가능성 너머의 품질

   1. 단순히 코드가 정답인지 또는 merge 가능한지만 보지 않는다.
   2. 시니어·스태프·프린시펄 엔지니어가 실제 코드베이스에서 보여줄 법한 판단과 ‘맛(taste)’을 보아야 한다.
   3. 패치가 불필요하게 커지지 않고(bloat 최소화), 기존 코드베이스 관행과 어울리며, 자율적으로 신뢰할 수 있는지를 측정한다.

3. 검증기의 신뢰성과 유연성 사이의 축

   1. 미리 작성한 검증기와 유닛 테스트는 높은 신뢰성·낮은 유연성을 가진다. 실제 코드 경로를 실행하므로 확실하지만, 정해진 해법과 다른 정상 구현을 거짓 음성으로 탈락시킬 수 있다.
   2. LLM 판사는 낮은 신뢰성·높은 유연성을 가진다. 다양한 코드 형태를 볼 수 있지만 코드를 직접 실행하지 않으므로 그럴듯하지만 틀린 해법을 과대평가할 수 있다.
   3. 단일 방식으로 양 끝을 택하기보다 전문가 판단을 결정론적 코드 실행으로 바꾸는 중간 지점이 필요하다.

2.6. Validation Agent로 전문가 판단을 확장하는 방법

1. 전문가가 validation spec을 작성한다

   1. CodeEx나 Claude Code 같은 코딩 에이전트가 입력 지시에 대한 패치를 생성한다.
   2. 전문가는 사용자 스토리, 기능·비기능 요구사항, 중요한 엣지 케이스를 몇 개의 불릿으로 적은 validation spec을 만든다.
   3. 특정 구현을 강제할 정도로 과도하게 처방하지 않고, 모델이 해야 할 일과 하지 말아야 할 일의 공간을 표현한다.

2. 에이전트가 결정론적 테스트로 바꾼다

   1. validation agent는 패치와 validation spec을 함께 받아 실제 코드 표면에 실행할 테스트 스크립트를 만든다.
   2. 스크립트는 코드 자체를 실행해 기능을 검사하므로, 단순히 코드를 눈으로 읽는 LLM 판사보다 실제 경로에 가깝다.
   3. 실행 결과와 별도의 판정을 함께 사용해 실행이 정상인지, 보상 해킹이나 에이전트 간 담합(collusion)이 있었는지를 확인한다.

3. 캘리브레이션과 품질 측정

   1. 내부 테스트 엔지니어와 전문 네트워크의 판단에 맞춰 validation agent를 조정했다.
   2. LLM 판사는 테스트의 fidelity(사양 충실도), completeness(완전성), collusion 여부 등을 측정하는 보조 역할을 한다.
   3. validation spec은 며칠·몇 주·몇 달이 걸릴 수 있는 완전한 명세와 테스트를 직접 쓰지 않고도 사용 사례·엣지 케이스의 모양을 지정하는 파라미터가 된다.
   4. 이렇게 전문가의 직관을 한 번 인코딩하면 여러 동적 구현에 재사용할 수 있다.

4. Tasteful Pass라는 새 지표

   1. tasteful pass는 정답률이나 병합 가능성만이 아니라 코드베이스 관행에 맞는지, 시니어 엔지니어처럼 행동하는지, 패치 크기의 불필요한 부풀림을 줄이는지를 평가한다.
   2. 발표자는 이 지표로 재검증한 결과 지난주 기준 Fable, Opus, Soul이 공동 1위라고 말했다.
   3. 이 벤치마크는 고정된 표가 아니라 최신 모델을 계속 반영하는 라이브 대시보드이자 살아 있는 벤치마크다.

2.7. 데이터 2.0의 전망과 공개 벤치마크 요청

1. 사람을 더 투입하는 것만으로는 부족하다

   1. 환경은 더 동적이고 복잡해진다.
   2. 출력은 점점 검증하기 어렵고, 미묘하며, 주관적으로 변한다.
   3. 에이전트의 자율성은 더 긴 작업으로 확장된다.
   4. 이 세 축이 서로 곱해지며 복잡성을 누적시키므로, 전문가가 자신의 감독과 판단을 행사할 수 있도록 설계하는 데이터 연구가 필요하다.

2. 더 많은 벤치마크가 필요한 이유

   1. Agents Exam, Berkeley의 Continual Learning Bench, τ-bench, Terminal-Bench 등과 협력하며 복잡한 에이전트 평가를 발전시키고 있다.
   2. 새로운 벤치마크는 데이터 연구를 촉진하는 높은 레버리지 수단이다.
   3. Snorkel은 Open Benchmarks Grants를 통해 커뮤니티의 벤치마크 개발과 연구팀 협력을 지원하겠다고 밝혔다.

3. 볼로 쿨레쇼프 — 확산 언어 모델과 현실적인 RL 환경

3.1. 순차 생성 대신 병렬 정제하는 확산 언어 모델

1. 생성 방식의 차이

   1. 전통적인 자기회귀(autoregressive) 언어 모델은 왼쪽에서 오른쪽으로 토큰을 하나씩 순차 생성한다.
   2. 확산 언어 모델(diffusion language model)은 노이즈가 섞인 초기 시퀀스 또는 초기 추정에서 출발한다.
   3. 여러 토큰을 한 번에 생성하고 여러 차례의 정제 단계에서 전체 시퀀스를 병렬로 개선한다.

2. 속도가 만드는 제품 기회

   1. 여러 토큰을 한 단계에 처리하므로 초당 1,000토큰을 넘는 속도가 가능하다.
   2. 실시간 AI, 고객지원·교육용 실시간 음성 에이전트처럼 지연시간이 사용자 경험을 결정하는 제품에 적합하다.
   3. 더 빠른 모델은 같은 크기의 모델로 상호작용을 매끄럽게 만들거나, 더 큰 모델을 쓰거나, 더 오래 추론하게 해 품질을 높일 수 있다.

3. 실시간 음성 파이프라인

   1. 기존 음성 시스템은 음성-텍스트(STT), 가운데의 LLM, 텍스트-음성(TTS)을 직렬로 연결하는 캐스케이드 구조다.
   2. 전체 지연시간은 가운데 LLM에 크게 막힌다.
   3. Inception의 Mercury 2가 초당 1,000토큰 수준으로 실행되면 대화가 더 자연스러워지고, 같은 시간 안에 큰 모델 또는 긴 추론을 사용할 수 있다.

3.2. Mercury 2가 보여주는 속도·품질 프런티어

1. 레이턴시와 품질의 파레토 프런티어

   1. 음성 벤치마크에서 x축은 레이턴시, y축은 품질이다.
   2. Mercury 2는 확산 방식으로 속도와 품질을 동시에 개선하는 새로운 파레토 프런티어를 만든다고 설명됐다.
   3. 1,200억 파라미터급 GPOSS 모델을 Cerebras에서 실행한 기준선보다 Mercury 확산 모델이 해당 측정과 실제 데이터에서 더 높은 품질을 내면서 더 빠르게 실행될 수 있다고 주장했다.

2. 하드웨어 대신 소프트웨어로 속도 얻기

   1. Cerebras 같은 특수 칩은 자기회귀 모델을 매우 빠르게 실행하도록 설계됐다.
   2. 확산 모델은 더 지능적인 소프트웨어만으로 상용 GPU에서 비슷한 속도를 얻을 수 있다.
   3. 값비싼 특수 하드웨어에 한정되지 않고 더 쉽게 구할 수 있는 GPU에 배포할 수 있다는 점이 확산 방식의 실용적 장점이다.

3. 알고리즘만으로는 충분하지 않다

   1. 확산 알고리즘이 한 축이라면, 좋은 음성 모델을 만드는 다른 축은 학습 데이터와 평가 데이터다.
   2. 모델이 빠른 것뿐 아니라 현실의 복잡한 상호작용을 제대로 처리하는지 측정할 데이터가 필요하다.

3.3. τ-bench의 한계와 현실 데이터의 필요성

1. 현실의 복잡성을 충분히 담지 못하는 평가

   1. τ-bench는 널리 사용되는 대표적 에이전트 평가지만 실제 고객지원 업무의 복잡성을 모두 담지 못한다.
   2. τ-bench 환경의 사양 수는 실제 기업 고객지원 환경보다 한 자릿수 이상 적을 수 있다.
   3. 사용할 수 있는 도구도 더 적고, 현실 업무에 필요한 일부 사양이 빠져 있다.

2. 벤치마크 과최적화(benchmaxing)

   1. 선호하는 벤치마크 웹사이트에서는 대부분의 모델 점수가 90점대처럼 보인다.
   2. 같은 모델을 실제 운영 로그에 실행하면 점수는 훨씬 낮아지고 모델 크기별 차이도 훨씬 커진다.
   3. 따라서 알고리즘 성능을 말하려면 벤치마크용 데이터뿐 아니라 실제 사용자 상호작용과 일치하는 데이터가 필요하다.

3.4. Tao Forge: 실제 사용에서 합성 RL 환경을 만드는 시스템

1. 입력과 목표

   1. Inception은 Tao Forge라고 부르는 에이전트 시스템을 사용해 현실적인 RL 환경을 합성한다.
   2. 시스템은 여러 에이전트를 조율하는 하네스이며, τ-bench와 비슷하지만 더 넓은 합성 환경을 평가와 학습에 제공한다.
   3. 환경 설명과 목표 도메인의 실제 사용자 상호작용·로그·데이터 제공자 자료를 입력으로 받는다.
   4. 예를 들어 은행 고객지원 환경과 그 환경에서 모델이 실제로 어떻게 사용되는지를 나타내는 아티팩트를 생성하도록 요청할 수 있다.

2. 초기 환경의 구성

   1. 정책(policy)은 은행의 운영 시간, 사용자 유형, 계좌 종류, 업무 규칙을 정의한다.
   2. 작은 데이터베이스와 모델이 상호작용할 도구도 함께 만든다.
   3. 실제 사용 데이터에 조건을 걸면 나중에 운영될 모델 사용 방식과 환경이 닮게 된다.
   4. 실제 로그가 없으면 인터넷을 크롤링해 대표적인 기업 정보를 담은 Business Knowledge Graph를 사용한다.

3. 시나리오·시드·페르소나에서 업무 생성

   1. 환경이 만들어지면 다음 핵심 산출물은 사용자가 달성하려는 목표를 담은 업무(task)다.
   2. 시드 데이터베이스에는 계좌 개설, 계좌 폐쇄, 전화번호 변경, 정보 요청 같은 추상 시나리오가 들어간다.
   3. 페르소나는 환경과 상호작용할 여러 유형의 사용자다.
   4. 에이전트가 시나리오와 페르소나를 은행·항공·의료 같은 도메인에 맞게 구체화하고, 다른 에이전트가 실제 사용자 역할을 시뮬레이션한다.

4. 난이도 조정과 hardening traps

   1. 너무 쉬워 모델이 계속 풀면 학습 신호가 없고, 너무 어려우면 성공과 실패를 구분할 신호가 부족하다.
   2. 모델의 해결 능력을 보면서 과제를 반복적으로 필터링하고 재구성한다.
   3. hardening trap은 정보를 일부 제거하거나 요구사항을 복잡하게 만들어 작업을 어렵게 하는 장치다.
   4. 현실성을 유지하면서도 모델이 학습할 수 있는 적절한 난이도까지 강화하거나, 지나치게 어려운 작업을 제외한다.

5. 운영 로그로 하네스를 되먹임하기

   1. 생성된 환경과 작업은 실제 운영 데이터와 계속 비교·점검한다.
   2. 하네스와 검증기를 갱신하고, 해당 환경에서 학습한 모델이 실제 사용자에게 받은 피드백을 다시 합성 절차에 반영한다.
   3. 합성 환경은 현실을 대체하는 고정된 모형이 아니라 운영 데이터와 함께 계속 수정되는 시스템이다.

3.5. 합성 환경이 Mercury 모델에 준 성능 개선

1. Mercury 2.5 실험

   1. 도메인 특화 데이터를 학습하기 전 Mercury 2.5의 정확도는 약 50%였다.
   2. Tao Forge에서 합성한 초기 작업 세트로 학습하자 별도의 환경 세트에서 성능이 23% 이상 개선됐다.
   3. 개선된 모델은 여러 최첨단 오픈·클로즈드 모델과 비슷한 수준에 도달했다.

2. 일반화가 가능한 실험 분할

   1. 은행 업무, 비행기 표 예약, 의사 예약처럼 서로 다른 비즈니스와 환경을 다양하게 구성했다.
   2. 비즈니스를 학습 세트와 테스트 세트로 나누고, 학습 세트에서만 반복 개선(hill-climbing)했다.
   3. 테스트 세트는 실제 로그에서 밀접하게 파생하되 학습에 사용하지 않은 비즈니스로 구성해 과적합을 줄였다.
   4. 다른 기업과 현실 로그에서 성능이 상관될 가능성이 높다는 점이 이 설계의 신뢰 근거다.

3. 제품 접근성과 스타트업 프로그램

   1. Mercury 2 계열은 초당 1,000토큰으로 실행되며 지연시간 민감도가 높은 음성 외에도 검색과 코드 영역에 사용된다.
   2. Inception은 YC 스타트업에 50만 달러의 크레딧을 제공하는 프로그램을 운영한다.
   3. 발표자는 관심 있는 창업자에게 행사 후 직접 설명하겠다고 안내했다.

4. 셰인 롱프리 — 다국어 사전학습의 시너지·간섭·스케일링 법칙

4.1. 영어 중심 연구를 넘어 데이터 출처의 상호작용을 보라

1. 연구 배경

   1. Shayne은 MIT에서 5년간 박사과정을 마쳤고 Google 인턴 기간에 가장 좋아하는 프로젝트를 수행했다.
   2. Google TPU를 사용해 다국어 사전학습과 언어 간 전이를 연구했다.
   3. 한 언어의 데이터뿐 아니라 서로 다른 언어 데이터셋 출처가 만드는 시너지, 간섭, 상호작용을 측정했다.

2. 언어를 넘어선 일반화

   1. 실험 방법은 언어에만 적용되지 않는다.
   2. 서로 다른 도메인, 품질이 다른 데이터 출처, 임의로 나눈 데이터 조각 사이의 상호작용에도 그대로 적용할 수 있다.
   3. 모델의 능력·위험·한계를 이해하려면 각각의 데이터 조각이 결합되어 어떤 결과를 만드는지 봐야 한다.

3. 영어 편향의 문제

   1. 당시 스케일링 법칙과 mixing law 논문의 99%가 영어 학습 데이터와 영어 평가에 관한 것이었다.
   2. 인터넷에서 풍부한 첫 몇 개 언어를 지나면 데이터가 급격히 부족해지므로 나머지 세계의 언어에는 별도의 제약이 생긴다.
   3. 각 문화·사회·언어에 맞는 모델을 만들려면 단순히 영어 모델의 규모를 복제하는 방식으로는 부족하다.

4.2. 태국어 사례: 부족한 단일언어 데이터와 과적합

1. Thai 데이터의 희소성

   1. 태국어는 약 8,000만 명의 사용자가 있는 언어지만, Madlad-400이라는 Common Crawl 기반 사전학습 코퍼스에서 태국어 토큰 수는 영어의 0.6%에 불과하다.
   2. 프런티어 모델의 자연어 혼합은 대체로 영어가 가장 많고, 웹에 더 풍부한 언어가 뒤를 잇는 분포를 따른다.
   3. 태국어는 전체 혼합에서 아주 작은 조각이 되므로 거대한 모델에서도 태국어 사용자를 위한 성능은 상대적으로 낮을 수 있다.

2. 태국어만 학습하는 전략의 문제

   1. 태국어 데이터만 모아 단일언어 모델을 만들면 데이터가 적어 같은 샘플을 반복 학습하게 된다.
   2. 여러 epoch에 걸쳐 데이터를 되풀이하면 태국어에 과적합한다.
   3. 과적합을 피하려면 더 작은 모델을 써야 하므로 충분한 표현력도 잃는다.

3. 혼합 데이터가 만드는 절충안

   1. 태국어 데이터를 충분히 사용하되 수익 체감이 시작되면 다른 언어의 고품질·상보적 데이터를 함께 넣는 방식이 바람직하다.
   2. 실험적으로 영어, 인도네시아어, 말레이어, 라오어, 크로아티아어가 태국어에 도움이 될 수 있었다.
   3. 어떤 언어가 유용한지는 언어 계통이 비슷한지로만 결정되지 않는다.
   4. 다른 출처가 실제로 덜 시끄럽고 비슷한 주제를 덮는지는 데이터에서 경험적으로 측정해야 하며, 언어학자의 이론만으로 추론할 수 없다.

4.3. 언어 간 시너지를 효율 격차로 측정하기

1. 학습 곡선 비교

   1. 태국어만 학습한 모델은 초반에는 잘 올라가지만 일찍 평평해진다.
   2. 태국어와 영어, 태국어와 텔루구어 등 50 대 50 혼합 모델의 학습 곡선을 비교하면 어느 언어 조합이 태국어에 더 유용한지 알 수 있다.
   3. 곡선 사이의 거리가 특정 언어가 목표 언어를 돕는 정도를 나타내는 효율 격차(efficiency gap)가 된다.
   4. 예시로 인도네시아어가 영어보다, 영어가 텔루구어보다 태국어에 더 유용한 조합이 관찰됐다.

2. 전이와 간섭의 해석

   1. 두 곡선이 가깝고 효율 격차 값이 크고 양수이면 긍정적 전이와 시너지를 뜻한다.
   2. 곡선이 멀고 값이 음수이면 부정적 전이, 즉 간섭이다.
   3. 간섭하는 언어들은 모델 내부의 토큰·뉴런 표현 공간을 놓고 경쟁해 서로의 성능을 낮춘다.

3. 교차언어 전이 행렬

   1. 여러 실험을 반복하면 행렬의 빨간색은 높은 시너지, 파란색은 높은 간섭을 나타내는 교차언어 전이 행렬을 얻는다.
   2. 스페인어 행을 보면 포르투갈어·이탈리아어·프랑스어가 밝은 빨간색으로 나타나는 경향이 있다.
   3. 스페인어에 가장 해로운 언어로 일본어가 나타났으며, 일본어를 섞으면 스페인어 성능이 떨어질 수 있다.
   4. 언어별 도움의 폭은 복잡하고, 널리 유용한 언어도 있으며 특정 목표에만 유용한 언어도 있다.

4.4. 모델 크기와 방향성에 따른 상호작용 변화

1. 큰 모델은 시너지를 수용한다

   1. 고정된 모델 크기에서 얻은 행렬을 더 큰 모델에 적용하면 파란색이 빨간색으로, 또는 더 짙은 빨간색으로 바뀌는 경우가 많다.
   2. 충분히 큰 모델은 여러 언어의 공통 패턴을 동시에 표현할 공간이 있어 시너지를 얻는다.
   3. 모델이 작아지면 대부분의 조합이 파란색으로 바뀌고, 언어들이 한정된 내부 표현 공간을 차지하려 경쟁한다.

2. 시너지는 대칭이 아니다

   1. 청중에게 “포르투갈어가 스페인어에 도움이 되면 스페인어도 포르투갈어에 도움이 되는가?”를 물었고, 손든 사람은 대략 반반이었다.
   2. 측정 결과는 대칭이 아니었다.
   3. 텔루구어가 스와힐리어에 유용하다는 결과를 얻어도 역방향을 가정하면 안 되며, 실무자는 각각의 방향을 따로 측정해야 한다.
   4. 방향별 관계에 분기(branching factor)가 생기므로 단순한 언어 유사성 그래프로 충분하지 않다.

3. 문자 체계와 언어 계통

   1. 청중에게 같은 문자(script)를 공유하는 언어와 같은 언어 계통(family) 중 무엇이 더 도움이 되는지 투표하게 했다.
   2. 둘 다 영향을 주지만 문자 체계가 조금 더 중요하다는 결과가 나왔다.
   3. 토큰화 아티팩트와 문자가 모델 입력으로 표현되는 방식이 이 차이를 만들 가능성이 있다.

4.5. 다국어 스케일링 법칙 만들기

1. Chinchilla식 법칙의 확장

   1. Chinchilla식 스케일링 법칙은 모델 크기와 학습 데이터 양으로 손실(loss)을 예측하고 파라미터를 맞춘다.
   2. 프랑스어 성능처럼 특정 목표 언어의 손실을 예측할 때는 프랑스어 데이터 양만 볼 수 없다.
   3. 다른 언어 데이터가 얼마나 많고, 목표 언어와 어떤 시너지를 갖는지도 동시에 모델링해야 한다.

2. 데이터 항을 구성하는 방법

   1. 기존 Chinchilla의 데이터 항을 목표 언어의 단일언어 데이터, 전이 행렬에서 가까운 전이 언어, 나머지 모든 언어의 버킷으로 나눈다.
   2. 같은 데이터를 여러 epoch 반복할 때 생기는 수익 체감도 반영한다.
   3. 전이 행렬에서 학습한 가중치가 각 언어 출처가 목표 언어 손실에 미치는 영향을 조정한다.

3. 실무적 유용성

   1. 모든 조합을 알아내려고 수백 번, 발표자의 표현으로는 700번의 사전학습 실험을 직접 돌리기는 어렵다.
   2. 이 방법은 데이터 출처를 혼합할 때 상호작용을 예측하고, 주어진 데이터와 컴퓨트로 모델을 얼마나 키울지 결정하는 실용적 기계가 된다.
   3. 발표자는 이 접근이 실제로 매우 잘 작동한다고 평가했다.

4.6. 사전학습·미세조정·다국어 확장의 의사결정

1. 기존 다국어 모델을 활용할지 새로 학습할지

   1. 이미 큰 다국어 사전학습 모델이 있을 때 목표 언어를 위해 단순히 미세조정할지, 처음부터 사전학습할지 선택해야 한다.
   2. 보유한 컴퓨트 규모에 따라 어느 전략이 유리한지 스케일링 분석으로 판단할 수 있다.
   3. 실무자는 언어별 데이터 양과 혼합 시너지를 측정한 뒤 전략을 선택해야 한다.

2. 다국어 사용의 저주

   1. 네 언어를 지원하던 모델을 여덟 언어로 확장하면 같은 성능을 유지하기 위해 데이터가 얼마나 더 필요한지 계산해야 한다.
   2. 모델 크기도 얼마나 커져야 하는지 함께 산정해야 한다.
   3. 이 문제는 단순히 언어 수를 두 배로 늘리는 문제가 아니라 각 언어의 데이터 희소성, 전이·간섭, 표현 공간 경쟁을 함께 고려해야 하는 문제다.

3. 연구의 최종 메시지

   1. 다국어 학습 곡선과 시너지 행렬은 데이터 출처를 무작정 섞지 않고 목표 언어별로 최적 혼합을 설계하게 해준다.
   2. 연구 결과는 다양한 목표 언어에서도 실무자가 무엇을 해야 하는지 알려주는 도구로 작동한다.
   3. 셰인은 관심 있는 사람에게 해당 자료와 수학적 세부사항을 참고하라고 권하며 발표를 마쳤다.

주요 발언 모음

“정답은 데이터를 보는 것입니다. 모든 거짓 양성과 거짓 음성을 보고 가장 큰 문제가 무엇인지 찾아야 합니다.” — 프랑수아 샤우바드

“데이터 사업의 최종 가치가 0달러라는 생각은 정말, 정말 틀렸습니다.” — 프랑수아 샤우바드

“데이터셋과 환경을 제품으로 생각해야 합니다.” — 프랑수아 샤우바드

“전문가의 머릿속에 있는 좋은 결과의 사양을 데이터셋으로 옮기는 일이 진짜 병목입니다.” — 빈센트 선 첸

“요즘 우리는 코딩 에이전트를 시니어 엔지니어처럼 믿지만, 여전히 주니어 엔지니어처럼 평가하고 있습니다.” — 빈센트 선 첸

“확산 모델은 더 똑똑한 소프트웨어로 GPU에서 빠르게 실행될 수 있습니다.” — 볼로 쿨레쇼프

“실제 운영 로그에서 모델을 돌리면 벤치마크 점수보다 훨씬 낮고, 모델 크기별 차이도 더 커집니다.” — 볼로 쿨레쇼프

“언어 간 도움은 대칭이라고 가정할 수 없습니다. 직접 측정해야 합니다.” — 셰인 롱프리

핵심 데이터 & 수치

• 2016년: 프랑수아가 박사과정을 떠나 Focal Systems를 시작한 시점.
• 1,000억 달러 이상: 지난 10년 데이터 기업이 만든 것으로 제시된 시가총액 규모.
• 85% F1: 핫도그/비핫도그 면접 질문의 모델 성능 예시.
• ImageNet의 약 30~40%: 개 또는 개 품종 이미지로 언급된 비중.
• 5% 대 95%, 이후 3% 대 97%: 박사과정에서 데이터 대 아키텍처에 쓴 시간과, 오늘날 생산 환경에서 강조되는 시간 배분의 대비.
• 1,000억 시간: Salesforce 자동화에서 이미 보유했을 법한 사용 기록을 과장해도 UI 변경 뒤에는 새 데이터가 필요하다는 사례의 수치.
• 약 1,200억 파라미터: Cerebras에서 실행한 GPOSS 기준선 모델의 규모.
• 초당 1,000토큰 이상: Mercury 확산 언어 모델의 추론 속도.
• 약 50% → 23% 이상 개선: 도메인 특화 학습 전 Mercury 2.5의 초기 정확도와 Tao Forge 작업으로 학습한 뒤 별도 환경에서 얻은 개선폭.
• 50만 달러 크레딧: YC 스타트업 대상 Inception 프로그램.
• 99%: 발표자가 지적한 영어 학습·영어 평가 중심 스케일링 법칙 논문의 비중.
• 약 8,000만 명: 태국어 사용자 수의 예시.
• 0.6%: Madlad-400에서 태국어 토큰이 영어 토큰에 비해 차지하는 비중.
• 4개 → 8개 언어: 다국어 모델 확장 시 같은 성능을 유지하기 위해 필요한 데이터와 모델 크기를 묻는 사례.

결론 및 시사점

1. 모델 아키텍처를 바꾸기 전에 운영 오류를 데이터 버킷으로 분류하고 가장 큰 실패 원인을 새 데이터·라벨·환경으로 해결해야 한다.
2. 데이터셋은 한 번 내려받고 끝나는 파일이 아니라 UI·사용자·업무 규칙·모델 능력이 바뀔 때마다 갱신되는 제품이다.
3. 전문가가 모든 샘플을 직접 채점하게 하지 말고, 전문가의 판단 규칙·사용자 스토리·검증 사양을 코드와 실행 가능한 테스트로 인코딩해야 한다.
4. 에이전트 평가에는 정답성뿐 아니라 긴 작업 궤적, 현실적인 지시, 코드베이스의 취향, 패치의 절제, 보상 해킹 방지까지 포함해야 한다.
5. 고정된 유닛 테스트는 신뢰성이 높지만 유연성이 낮고, LLM 판사는 유연하지만 신뢰성이 낮으므로 validation agent처럼 전문가 판단과 결정론적 실행을 연결하는 중간 구조가 필요하다.
6. 확산 언어 모델이 초당 1,000토큰을 내더라도 실제 고객지원·음성·검색·코드 환경과 동떨어진 평가 데이터만 사용하면 제품 성능을 보장할 수 없다.
7. RL 환경은 실제 로그, 기업 지식, 시나리오, 페르소나, 난이도 조정, 검증기, 운영 피드백을 하나의 반복 시스템으로 묶어야 한다.
8. 희소 언어를 위한 모델은 해당 언어 데이터를 무한 반복해 과적합시키기보다 경험적으로 도움이 확인된 다른 언어를 혼합해야 한다.
9. 언어 간 전이는 대칭이 아니며, 문자 체계와 토큰화가 언어 계통보다 더 큰 영향을 줄 수 있으므로 방향별 측정이 필요하다.
10. 다국어 모델의 데이터 혼합·모델 크기·미세조정·처음부터 학습하기의 선택은 Chinchilla식 법칙과 전이 행렬을 함께 사용해 컴퓨트 예산에 맞춰 결정해야 한다.
11. 다음 데이터 혁신의 핵심은 더 많은 사람을 단순 반복 투입하는 것이 아니라, 적은 수의 전문가가 더 넓은 데이터와 환경에 판단을 재사용하도록 만드는 연구다.
12. 공개 벤치마크와 데이터 연구 보조금은 모델의 실제 능력을 측정할 공통 언어를 만들고, 데이터가 AI 경제의 지속적인 병목이자 독립적인 산업으로 성장하도록 돕는다.