Going In Deep On Data

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Going In Deep On Data를 중심으로, 표현력이 높은 모델이 보편화한 뒤에는 아키텍처 조정보다 거짓 양성·거짓 음성·정보 부재·분포 변화를 구분하고 필요한 데이터를 보강를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 표현력이 높은 모델이 보편화한 뒤에는 아키텍처 조정보다 거짓 양성·거짓 음성·정보 부재·분포 변화를 구분하고 필요한 데이터를 보강하는 일이 성능 개선의 중심이 된다.
2. 데이터셋과 강화학습 환경은 한 번 만들어 배포하는 압축 파일이 아니라 온톨로지, 최신 업무 흐름, 주관적 선호, 운영 피드백을 계속 반영해야 하는 제품이다. Salesforce 기록을 아무리 많이 확보해도 UI가 바뀌면 새 궤적이 필요한 사례가 이를 보여준다.
3. 수작업 라벨링은 데이터와 비용이 함께 증가하는 O(n) 구조이며, 중복 라벨링과 스키마 변경까지 고려하면 확장성이 더 낮아진다. 전문가 감독을 라벨링 함수로 인코딩하고 약한 신호의 정확도와 상관관계를 추정하는 데이터 프로그래밍은 희소한 판단을 재사용 가능한 소프트웨어로 바꾼다.
4. 코딩 에이전트처럼 장시간 환경을 다루는 모델은 HumanEval 수준의 정답 평가만으로 측정하기 어렵다. Senior SWE-Bench와 검증 에이전트는 현실적인 고수준 지시, 실행 가능한 결정론적 테스트, 코드베이스 적합성, 보상 해킹 점검을 결합해 시니어 수준의 결과를 평가하려 한다.
5. 확산 언어 모델의 초당 1,000토큰급 생성, Tau Forge의 운영 기반 합성 환경, 다국어 전이 행렬과 확장형 스케일링 법칙은 서로 다른 문제처럼 보이지만 모두 데이터의 현실성·혼합·평가 설계가 모델 성능과 배포 가치를 좌우한다는 공통 결론으로 이어진다.

🧩 배경과 문제 정의

• 표현력이 높은 모델 아키텍처가 보편화하면서 성능 병목은 아키텍처 조정에서 데이터의 품질·범위·최신성으로 이동했다.
• 현실의 데이터 분포와 업무 환경은 계속 변하므로, 방대한 데이터를 한 번 수집하는 것만으로는 생산 환경의 오류를 해결할 수 없다.
• 전문 영역의 자동화에는 전문가의 판단을 데이터와 강화학습 환경으로 전환해야 하지만, 전문가의 수와 시간은 제한적이어서 판단을 확장하는 기술이 필요하다.
• 단순 라벨에서 장시간 작동하는 에이전트 환경으로 과제가 복잡해지면서, 재사용 가능한 감독 방식과 현실적인 벤치마크가 함께 중요해졌다.

🕒 시간순 섹션별 상세정리

1. 아키텍처보다 데이터를 먼저 봐야 하는 이유

• 2016년에는 다수의 투자자가 데이터 사업의 종착 가치를 0달러로 봤지만, 이후 약 1,000억 달러의 시가총액이 생기며 데이터가 단순 원자재라는 가정이 무너졌다. [00:57]
• F1 점수 85% 이후에는 활성화 함수나 계층 수를 바꾸기보다 거짓 양성과 거짓 음성을 분류해 가장 큰 오류 유형부터 찾아야 한다. 안개나 사람의 가림처럼 정보 자체가 없는 문제는 아키텍처 변경만으로 해결할 수 없다. [01:42]

2. 깨끗한 학습셋 밖에서 무너지는 모델

• 정돈된 학습 분포와 달리 생산 환경에는 훈련에서 보지 못한 입력이 계속 들어오며, 모델은 이런 분포 변화 앞에서 급격히 작동하지 않게 된다. [03:26]
• 경제 활동을 자동화하려면 검증 가능한 보상을 제공하는 전문가 데이터와 강화학습 환경뿐 아니라, 디자인·코드 품질·의료 판단처럼 정답이 주관적인 선호 데이터도 필요하다. [03:37]

3. 데이터의 지속적 갱신과 전문 기록의 부족

• Salesforce 사용 기록을 1,000억 시간 확보해도 UI가 바뀌면 기존 궤적만으로는 자동화가 작동하지 않으므로, 충분한 데이터가 있어도 새 데이터를 계속 수집해야 한다. [05:28]
• 현재의 주요 병목은 아키텍처·GPU·전력이 아니라 데이터이며, 변화하는 환경과 전문 업무를 반영하지 못하면 계산 자원을 늘려도 성능이 따라오지 않는다. [05:47]

4. LLM 능력을 확장하는 앱으로서의 데이터

• 스마트폰이 배달·이동·길 안내 기능을 앱으로 얻듯이, LLM도 의사·회계사·변호사·트레이더 같은 역할을 수행하려면 각 영역의 최신 데이터와 강화학습 환경이 필요하다. [07:13]
• 필요한 데이터 기업의 수는 스마트폰에 필요한 앱의 수와 비슷하며, 전문 기능마다 독립적인 데이터 제품이 생길 수 있다. [07:35]

5. 30초짜리 라벨에서 수백 시간짜리 환경으로

• 효과적인 데이터셋의 병목은 의사·언론인 등 좋은 결과의 기준을 아는 전문가의 판단을 머릿속에서 꺼내 데이터로 옮기는 과정이다. [10:35]
• 데이터 1.0에서는 한 건당 약 30초의 판단으로 선호 라벨이나 프롬프트·응답 쌍을 만들 수 있었다. [11:44]

6. 수작업 라벨링의 구조적 한계

• 수작업 라벨링은 데이터 포인트마다 새로운 인지 작업이 필요한 O(n) 방식이어서 데이터 규모와 비용이 함께 증가한다. [12:50]
• 잡음을 낮추려면 동일 데이터를 여러 번 라벨링하는 k×n 작업이 필요하고, 스키마나 과제 정의가 바뀌면 처음부터 다시 시작해야 하며 판단 근거의 출처도 남지 않는다. [13:30]

7. 전문 지식을 소프트웨어로 옮기는 데이터 프로그래밍

• 전문가 감독을 소프트웨어로 인코딩하면 데이터를 프로그램으로 라벨링하고, 기준 변화에 맞춰 로직을 수정하며, 판단 근거를 감사하고 협업할 수 있다. [14:18]
• 스팸과 정상 메일을 구분하는 이유를 휴리스틱 기반 라벨링 함수로 표현하면 전문가의 암묵지를 재현 가능하고 확장 가능한 형태로 바꿀 수 있다. [14:49]

8. 정답 없이 약한 감독 신호를 결합하는 라벨 모델

• 여러 라벨링 함수는 서로 겹치고 부정확하므로, 완전한 정답 없이 약한 감독 신호의 품질과 상관관계를 추정해야 한다. [15:13]
• 정답지가 없는 교실에서 학생들의 답만으로 실력을 추정하듯 각 투표자의 정확도를 비지도 방식으로 학습하고, 베이즈 추론으로 실제 정답의 확률을 계산한다. [16:34]

9. 복잡해지는 코딩 에이전트와 시니어 벤치마크

• 코딩 에이전트 데이터의 난도는 입력·출력·실행 환경의 복잡성과 작업 시퀀스 길이를 따라 증가하며, 데스크톱 전체를 다루는 장시간 과제까지 범위가 넓어진다. [17:35]
• HumanEval 같은 기초 평가는 포화됐지만 복잡한 터미널 기반 과제는 여전히 어렵고, ProgramBench의 최신 모델 성능은 약 1%에 불과하다. [18:20]

10. 현실적인 지시와 코드의 ‘취향’까지 평가하는 설계

• Senior SWE-Bench의 지시는 세부 구현을 과도하게 지정하지 않고 Slack 메시지, 로그 묶음, 사용자 스토리처럼 현실에서 시니어 엔지니어가 받는 고수준 요구사항을 사용한다. [20:20]
• 보상은 코드의 정답 여부와 병합 가능성뿐 아니라, 스태프·시니어·프린시펄 엔지니어에게 무감독으로 맡길 수 있는 설계 감각과 코드베이스 적합성까지 측정한다. [20:52]

11. 단위 테스트와 LLM 심판 사이의 검증 딜레마

• 사전 작성한 단위 테스트는 실제 코드를 실행하므로 신뢰성이 높지만, 정해진 구현 형태에 묶여 다양한 유효 해법을 수용하기 어렵다. [21:40]
• 동일한 요구사항을 다른 구조로 올바르게 구현해도 고정된 검증기가 해당 경로를 예상하지 못하면 정상 코드를 실패로 판정하는 거짓 음성이 생긴다. [22:09]

12. 검증 에이전트로 신뢰성과 유연성 결합하기

• 검증 에이전트는 전문가가 작성한 사용자 스토리와 좋은 결과의 조건을 받아, 실제 해법과 관련된 코드 표면에 결정론적 테스트를 작성한다. [23:21]
• 코딩 모델이 만든 패치와 짧은 검증 명세를 함께 입력하면, 검증 에이전트가 기능·비기능 요구사항을 실행 가능한 테스트 스크립트로 변환한다. [24:21]

13. 검증 보정과 ‘테이스트풀 패스’ 결과

• 검증 에이전트는 테스트 엔지니어의 판단과 정렬하고, LLM 심판으로 충실도·완전성·공모 가능성을 측정해 생성된 테스트의 품질을 보정한다. [25:05]
• ‘테이스트풀 패스’는 정답과 병합 가능성을 넘어 코드베이스 관행 준수, 시니어 수준의 판단, 불필요한 패치 크기와 코드 팽창까지 평가한다. [25:45]

14. 데이터 2.0의 연구 과제와 공개 벤치마크

• 환경의 동적 복잡성, 검증하기 어려운 주관적 출력, 에이전트 자율성이 동시에 증가하면서 난도가 복합적으로 커지고, 전문가의 판단을 확장하는 데이터 연구가 필요하다. [27:37]
• 새로운 벤치마크는 실제 과제의 미해결 영역을 드러내고 후속 데이터 연구를 촉진하므로 높은 영향력을 가진 연구 수단이다. [27:53]

15. 병렬 생성으로 전환하는 확산 언어 모델

• 확산 언어 모델은 토큰을 왼쪽에서 오른쪽으로 하나씩 생성하지 않고, 잡음이 섞인 초기 시퀀스에서 모든 토큰을 만든 뒤 여러 단계에 걸쳐 병렬로 다듬는다. [29:27]
• 한 단계에서 여러 토큰을 생산할 수 있어 초당 1,000개가 넘는 토큰 속도에 도달하며, 순차적인 자동회귀 언어 모델의 생성 속도를 크게 넘어선다. [29:49]

16. 실시간 음성의 LLM 지연과 확산 모델의 속도 해법

• 고객지원·교육용 실시간 음성 에이전트는 음성인식→LLM→음성합성의 연쇄형 구조를 사용하며, 전체 응답 지연은 가운데 LLM 추론 속도에 크게 막힌다. [30:20]
• Mercury 2의 초당 1,000토큰 처리 속도는 대화를 더 자연스럽게 만들고, 같은 지연 예산에서 더 큰 모델이나 더 긴 추론을 사용해 품질을 높일 여지를 만든다. [30:46]

17. 실제 운영을 반영하지 못하는 벤치마크

• 우수한 음성 모델에는 확산 알고리즘뿐 아니라 학습·평가 데이터가 모두 필요하며, 데이터의 현실성이 실제 배포 성능을 좌우한다. [32:17]
• Tau-bench 환경은 실제 고객지원 시스템보다 명세가 약 한 자릿수 규모 적고 도구와 운영 규칙도 부족해, 현실에서 발생하는 복잡한 상호작용을 충분히 담지 못한다. [32:50]

18. 실사용 데이터로 구축하는 Tau Forge 환경

• Tau Forge는 데이터 제공업체와 운영 파트너의 실제 사용자 상호작용을 바탕으로 여러 도메인의 합성 강화학습 환경을 만들며, 같은 환경을 평가와 학습에 모두 활용한다. [33:53]
• 에이전트 오케스트레이션 시스템이 목표 도메인과 사용 사례를 입력받아 정책·사용자·계정·소형 데이터베이스·도구를 포함한 현실적인 업무 환경을 구성한다. [35:10]

19. 사용자 과업 생성과 난도 조절

• 계좌 개설·해지·전화번호 변경 같은 시나리오와 다양한 사용자 페르소나를 도메인에 맞게 특화한 뒤, 다른 에이전트가 실제 사용자 역할을 맡아 상호작용 과업을 생성한다. [36:42]
• 너무 쉬운 과업은 학습 신호가 없고 너무 어려운 과업도 개선 방향을 주지 못하므로, 정보 제거·요구사항 복잡화 같은 하드닝 기법과 필터링으로 적정 난도를 맞춘다. [37:23]

20. 합성 과업의 성능 향상과 실제 적용

• 도메인 특화 학습 전 약 50% 정확도였던 Mercury 2.5는 Tau Forge 합성 과업으로 학습한 뒤 별도 환경에서 성능이 23% 이상 향상돼 주요 공개·비공개 모델 수준에 도달했다. [38:25]
• 은행·항공권·진료 예약 등 서로 다른 업종을 학습 세트와 테스트 세트로 분리하고, 실제 운영 로그에서 파생한 테스트 과업을 사용해 과적합을 줄이고 배포 성능과의 연관성을 높였다. [39:09]

21. 영어 중심 연구를 넘어선 다국어 데이터 문제

• 다국어 사전학습 데이터는 언어마다 서로 돕거나 간섭하며, 같은 분석은 언어뿐 아니라 도메인·품질 등 서로 다른 데이터 원천의 결합에도 적용할 수 있다. [41:17]
• 기존 스케일링 법칙과 데이터 혼합 연구의 약 99%가 영어 학습·평가에 집중하지만, 온라인 데이터가 풍부한 소수 언어를 벗어나면 사용 가능한 데이터가 급격히 줄어든다. [42:28]

22. 태국어 사례로 본 데이터 희소성과 최적 혼합

• 약 8천만 명이 사용하는 태국어도 MADLAD-400에서 토큰 수가 영어의 0.6%에 불과해, 화자 규모에 비해 사전학습 자원이 극단적으로 부족하다. [43:25]
• 다국어 모델에서는 태국어 비중이 지나치게 작아 성능이 낮아지고, 태국어만으로 학습하면 같은 데이터를 여러 에폭 반복하면서 과적합돼 더 작은 모델을 선택해야 한다. [44:40]

23. 학습 곡선으로 측정하는 언어 간 전이

• 태국어 단일 학습 곡선과 태국어·다른 언어를 50대 50으로 혼합한 곡선의 거리는, 추가 언어가 태국어 학습 효율에 얼마나 도움을 주거나 손해를 끼치는지 나타낸다. [46:26]
• 두 곡선이 가까우면 강한 양의 전이가 발생하고 멀어지면 음의 전이가 커지며, 음의 전이에서는 언어들이 제한된 토큰과 모델 내부 표현 공간을 놓고 경쟁한다. [47:04]

24. 모델 크기·전이 방향·문자 체계의 영향

• 모델이 커지면 여러 언어의 공통 패턴을 수용할 공간이 늘어 간섭 관계가 시너지로 바뀌지만, 작은 모델에서는 언어들이 표현 공간을 두고 경쟁하면서 대부분의 조합이 간섭으로 기운다. [48:17]
• 언어 간 전이는 대칭이 아니어서 텔루구어가 스와힐리어에 유용하더라도 스와힐리어가 텔루구어에 같은 효과를 준다고 가정할 수 없으며, 각 방향을 따로 측정해야 한다. [49:08]

25. 다국어 혼합을 위한 확장형 스케일링 법칙

• 기존 Chinchilla 법칙은 모델 크기와 전체 데이터량으로 손실을 예측하지만, 다국어 모델에서는 목표 언어 데이터와 다른 언어 데이터의 기여도가 달라 단일 데이터 변수만으로 최적 혼합을 계산하기 어렵다. [50:30]
• 전체 데이터량을 목표 언어 데이터, 전이 효과가 큰 근접 언어군, 나머지 언어군으로 분해하고 반복 에폭의 한계효용 감소와 전이 행렬에서 학습한 가중치를 함께 반영한다. [51:09]

26. 파인튜닝·재학습과 다국어 확장 의사결정

• 사용 가능한 연산량을 기준으로 기존 대형 다국어 모델을 파인튜닝할지, 목표 언어를 위해 처음부터 사전학습할지 선택할 수 있다. [51:55]
• 지원 언어를 4개에서 8개로 늘릴 때 기존 성능을 유지하려면 데이터와 모델 크기를 얼마나 추가해야 하는지 계산해, 다국어 확장 과정의 성능 저하를 관리할 수 있다. [52:11]

🧾 결론

• AI 경쟁력은 보유 데이터의 절대량보다 어떤 오류와 업무 변화를 포착하고 얼마나 빠르게 데이터를 갱신할 수 있는지에 달려 있다.
• 데이터는 온톨로지·전문가 선호·강화학습 환경·검증기를 함께 관리하는 지속적인 제품이 되어야 한다.
• 전문가의 암묵지를 프로그램과 약한 감독으로 전환하면 판단 근거를 감사하면서 반복 활용할 수 있지만, 복잡한 환경을 설계하는 전문가 시간 자체는 여전히 핵심 제약이다.
• 실제 운영을 대표하지 못하는 포화 벤치마크는 모델 간 품질 차이를 가리므로, 평가 환경과 검증 기술도 학습 데이터만큼 중요한 연구·제품 영역이다.

📈 투자·시사 포인트

• 의료·법률·회계·트레이딩처럼 최신 전문 데이터와 선호 궤적이 필요한 영역에서는 여러 기반 모델에 공급할 수 있는 독립적인 도메인 데이터 제품이 중요한 가치 계층이 될 수 있다.
• 데이터 프로그래밍, 출처 추적, 환경 생성, 검증 에이전트처럼 전문가 판단을 확장하고 감사 가능하게 만드는 도구는 수작업 라벨링의 비용 구조를 개선할 기반 기술로 주목할 만하다.
• 실시간 음성·검색·코드 시장에서는 빠른 생성 모델만으로는 충분하지 않으며, 운영 로그를 반영한 현실적인 학습·평가 환경과 결합할 수 있는지가 배포 성능을 좌우한다.
• 저자원 언어와 다국어 모델에서는 무조건 데이터를 늘리기보다 언어별 전이·간섭, 반복 에폭의 한계효용, 모델 크기를 함께 계산하는 혼합 최적화 역량이 차별화 요소가 될 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 약 1,000억 달러의 데이터 기업 시가총액과 데이터에 약 97%의 노력이 투입된다는 수치는 집계 대상, 기간, 측정 방식이 제시되지 않아 일반화 범위를 확인해야 한다.
• ProgramBench 약 1%, Mercury 2의 초당 1,000토큰 이상, Tau Forge 학습 후 23% 이상 향상이라는 결과는 평가 세트, 하드웨어, 기준 모델, 절대 향상과 상대 향상의 구분이 상세히 제공되지 않았다.
• 검증 에이전트가 결정론적 실행과 LLM 심판을 결합하더라도 테스트 누락, 심판 편향, 공모와 보상 해킹을 실제로 어느 수준까지 차단하는지는 추가 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 생산 오류를 거짓 양성, 거짓 음성, 정보 부재, 분포 변화로 분류하고 가장 큰 오류 유형부터 데이터 수집 우선순위에 반영한다.
• 데이터셋의 온톨로지, 스키마, 판단 근거, 업무 환경 버전을 기록하고 변경 시 지속적으로 새 궤적을 수집하는 갱신 체계를 만든다.
• 반복되는 전문가 판단을 라벨링 함수로 인코딩한 뒤, 약한 감독 신호의 정확도와 상관관계를 추정하는 라벨 모델로 확장 가능성을 시험한다.
• 에이전트 평가는 현실적인 고수준 요구사항, 실제 코드 실행, 기능·비기능 테스트, 별도 심판, 보상 해킹 점검을 함께 포함하도록 설계한다.

❓ 열린 질문

• 제품과 업무 환경이 바뀌는 속도에 맞춰 데이터와 강화학습 환경을 어느 주기로 갱신해야 비용 대비 성능을 최적화할 수 있는가?
• 수백 시간이 필요한 데이터 2.0 환경을 만들 때 전문가의 희소한 시간을 가장 효율적으로 증폭하는 감독 인터페이스는 무엇인가?
• 검증 에이전트가 생성한 테스트의 충실도와 완전성을 특정 모델 계열에 과적합하지 않고 어떻게 지속적으로 보정할 수 있는가?