rl insights
앱 회사가 AI 벤치마크를 만드는 시대: Sean Cai
- Sean Cai의 핵심 주장은 최신 model scorecard를 보면 benchmark가 점점 app layer 회사에서 나오고 있다는 것임
- 예전에는 lab이 일반 데이터를 모아 범용 모델을 키웠다면, 이제는 finance, law, software engineering, bio처럼 domain별로 깊은 task와 benchmark가 필요해지는 단계임
- Perplexity, Databricks, Zapier, Sierra, Cursor, Cognition, LatchBio, Rogo, Harvey 같은 applied company들이 실제 사용자 query와 workflow에서 benchmark를 만들고 있음
- 이 흐름은 RLaaS, small model implementation, domain-specific post-training 수요가 app layer 쪽에서 커지고 있다는 신호로 볼 수 있음
- 한 줄로 말하면, 모델이 대학 전공을 고르는 단계에 들어가면서 domain별 시험지와 채점 기준을 가진 회사의 가치가 커진다는 주장임
왜 benchmark가 앱 회사에서 나오나?
- benchmark는 쉽게 말하면 모델 시험지임. 모델이 실제 일을 얼마나 잘하는지 재는 문제 모음과 채점 기준임
- 예전 benchmark는 일반 지식, 수학, 코딩 문제처럼 비교적 범용적인 것이 많았음
- 하지만 모델이 충분히 똑똑해지면 다음 병목은 “이 domain에서 실제 일을 잘하나”가 됨
- 이때 가장 좋은 문제를 가진 곳은 lab이 아니라 app layer 회사일 수 있음. 그 회사는 실제 고객, 실제 query, 실제 workflow, 실제 실패 사례를 매일 보기 때문
- 법률 AI 회사는 계약 검토 task를 알고, 금융 AI 회사는 analyst workflow를 알고, automation 회사는 여러 SaaS API를 엮는 업무를 알고 있음
- 그래서 durable benchmark, 즉 오래 의미 있는 시험지는 점점 현장에 가까운 applied company에서 나올 가능성이 큼
어떤 benchmark들이 이미 나오고 있나?
| 회사 | benchmark | 무엇을 재나 |
|---|---|---|
| Sierra | TauBench | customer service agent가 실제 대화와 정책을 따라 task를 해결하는지 |
| Perplexity | DRACO | real user query 기반 deep research 품질, 정확도, citation |
| Databricks | OfficeQA | Treasury Bulletin 문서 기반 숫자 추론과 grounded QA |
| Zapier | AutomationBench | 47개 앱을 넘나드는 end-to-end business workflow 수행 |
| Cursor | CursorBench | coding agent가 실제 개발 workflow에서 얼마나 잘하는지 |
| Cognition | Frontier Code | frontier coding agent 성능과 장기 task 처리 |
| LatchBio | SpatialBench | bio domain의 실제 spatial biology task |
| Rogo | Big Finance Benchmark | 금융 analyst와 investment workflow에 가까운 task |
| Harvey | Legal Agent Benchmark | 법률 agent가 실제 legal workflow를 처리하는 능력 |
- 공통점은 모두 실제 사용자 또는 실제 workflow에 가까운 task를 기반으로 한다는 점임
- 단순 Q&A보다 어렵고, 모델이 여러 단계로 생각하거나 도구를 쓰거나 domain 지식을 적용해야 함
- 이런 benchmark는 eval로도 쓰이고, 잘 설계하면 RL training environment로도 확장될 수 있음
데이터 공급망은 어떻게 쪼개지나?
- Sean Cai는 올해 초 data supply chain이 unbundle될 것이라고 봤음
- 과거 데이터 회사는 사람을 모아 라벨을 붙이는 쪽에 가까웠음. 이미지 박스 치기, 텍스트 분류, human feedback 같은 방식임
- 이제는 supply chain이 더 세분화됨. 어떤 회사는 domain expert를 모으고, 어떤 회사는 RL environment만 만들고, 어떤 회사는 verifier와 reward data를 만들 수 있음
- 동시에 horizontal domain도 나뉨. bio, finance, cyber, law, software engineering마다 필요한 task, expert, 채점 기준이 다름
- lab 입장에서는 모든 domain을 내부에서 깊게 알기 어려움. 그래서 domain-specific benchmark를 만드는 applied company와 협업하는 것이 자연스러운 방향이 됨
- 이건 app layer 회사가 단순 앱 판매자를 넘어, lab의 post-training과 eval에 필요한 data supplier가 될 수 있다는 뜻임
왜 범용 데이터보다 domain depth가 중요해지나?
- Sean Cai의 비유는 모델이 이제 초등학교를 지나 대학 전공을 고르는 단계에 왔다는 것임
- 초등학교 선생님은 수학, 문학, 과학, 역사 전반을 넓게 가르칠 수 있음. 하지만 대학 전공 수업은 domain depth가 필요함
- 모델도 비슷함. 범용 지식은 이미 많이 배웠고, 이제는 법률, 금융, bio, software engineering 같은 전공별 edge case를 배워야 함
- 그 edge case는 인터넷에 넓게 깔린 평범한 데이터보다, 실제 업무에서 생기는 실패와 예외에서 나옴
- 그래서 앞으로 중요한 data company는 “많은 데이터를 싸게 모으는 회사”보다 “특정 domain의 어려운 task를 검증 가능하게 만드는 회사”에 가까워질 수 있음
UseDesktop 관점
- 이 글은 UseDesktop 방향과 거의 맞닿아 있음
- 앞으로 작은 app layer 회사도 단순히 앱을 파는 게 아니라, 특정 workflow의 benchmark와 verifier를 쥐면 lab이 원하는 data supplier가 될 수 있음
- 특히 CUA 쪽은 실제 화면 업무에서 나온 task, trajectory, 성공 조건이 부족함
- 그래서 아주 좁은 vertical에서 시작해도, 그 workflow가 실제적이고 검증 가능하다면 좋은 RL data supply chain의 일부가 될 수 있음
app layer benchmark가 왜 중요한가요?
실제 고객 workflow에서 나온 문제이기 때문임. lab이 만든 일반 시험보다 production task와 더 가까워서, 모델이 실제 제품에서 잘할지 판단하는 데 더 유용할 수 있음.
RLaaS와 benchmark는 어떻게 연결되나요?
좋은 benchmark는 모델을 평가하는 시험지이고, 잘 만들면 RL 학습용 환경도 될 수 있음. task, 도구, 초기 상태, 성공 조건, verifier가 있으면 모델을 반복 rollout시키고 개선할 수 있음.
왜 domain-specific data company가 기회인가요?
모델이 범용 능력은 이미 강해졌기 때문임. 이제 차이는 법률, 금융, bio, cyber처럼 특정 영역의 어려운 문제와 채점 기준을 누가 갖고 있느냐에서 날 수 있음.