TL;DR

  • Jev 같은 System One 모델은 다양한 작업에 빠르게 대응하는 범용 분류기로, 성능이 검증된 뒤 전용 분류기로 대체할 수 있는 경로를 제공함.
  • 기존 분류기는 특정 작업에 맞춘 학습이 필요하지만, System One 모델은 프롬프트로 이메일 분류부터 Doom 플레이까지 처리함.
  • 전용 분류기 구축의 주요 장애물은 일반 엔지니어링 팀의 머신러닝(ML) 전문성 부족과 대규모 데이터셋 필요성임.
  • Jev에 입력된 데이터와 출력된 결정을 모으면 작업별 학습 데이터가 만들어져, 더 빠르고 저렴한 전용 분류기를 학습할 수 있음.
  • 범용 System One 모델을 활용해 기능의 가치를 먼저 검증한 뒤 전용 분류기로 증류하는 방식이 널리 쓰일 수 있음.

System One 모델과 기존 분류기

  • Jev 같은 “System One” 모델은 빠른 범용 분류기임. 분류기는 1958년부터 존재했지만 특정 작업에 맞춰 학습해야 하므로, 개를 식별하도록 만든 분류기는 신호등이 빨간색인지 또는 편지가 긴급한지 판별하는 데 쓸 수 없음.
  • 대형 언어 모델(LLM)처럼 Jev는 이메일 분류부터 Doom 플레이까지 다양한 작업을 프롬프트로 수행함.
  • LLM이 이론상 처리할 수 있어도 실제로는 느리고 비용이 많이 드는 작업이 존재함. 예를 들어 새 Slack 메시지를 하나씩 읽고 알림을 보낼지 판단하는 작업임.
  • 이런 작업에 전용 분류기를 학습하는 방법도 있지만, 일반 엔지니어링 팀 대부분은 분류기 구축에 필요한 전문성을 갖추지 못했고 대규모 데이터셋도 마련해야 함.

Jev로 작업별 데이터 수집

  • Jev는 프롬프트를 사용하는 방식으로 첫 번째 장애물을 해결함. 엔지니어링 팀은 “{기준 목록}을 바탕으로 이 메시지에 대해 사용자에게 알림을 보내야 하는가?”와 같은 프롬프트로 System One 모델을 연결할 수 있음.
  • Jev는 두 번째 장애물인 학습 데이터 마련도 해결할 수 있음. 프롬프트를 며칠간 조정해 분류기 성능이 만족스러워지면 입력과 출력을 간단히 수집할 수 있음.
  • Slack 알림 사례에서 입력 데이터는 Slack 메시지와 관련 맥락이며, 출력 데이터는 알림 여부에 대한 최종 결정임.
  • 충분한 데이터를 저장하면 그 데이터로 자체 분류기를 학습할 수 있음.

전용 분류기로의 대체

  • 진지한 작업에서는 직접 만든 전용 분류기가 Jev보다 항상 저렴하고 빠름. 범용 분류기는 다양한 작업을 처리하려고 관련 없는 지식까지 가중치에 담아야 하므로 규모가 더 크고 느리며 실행 비용도 높음.
  • 전용 분류기는 Jev 같은 범용 분류기는 아니지만, 특정 작업에서는 좋은 성능을 내면서 훨씬 빠르게 작동할 전망임.
  • 전용 분류기 개발에는 일부 ML 전문성이 필요하지만, 기능을 만들 가치가 있다고 검증한 뒤에는 그 전문성을 확보하거나 외부에서 빌리기가 더 쉬움.
  • 요컨대 Jev는 특정 작업에 맞춘 프롬프트를 사용하므로, 성공적인 활용 사례를 작업별 분류기로 증류하기 쉬움. System One 모델이 널리 확산된다면 이런 방식이 일반적인 패턴이 될 전망임.
  • 다른 사례를 원한다면 즉각 알림 대신 더 높은 빈도의 이벤트 소스를 적용할 수 있으며, LLM을 활용해 데이터를 수집하고 묶음 처리하는 방법도 고려할 수 있음.

주석

  • Jev를 쓰지 않고도 이미 LLM으로 데이터를 대량 주석 처리할 수 있지만, 기능이 제대로 작동할지 모르는 단계에서 진행하기에는 비용이 상당함.