영화 맨 인 블랙 2에서 요원 J는 겉보기엔 평범한 우체국에서 K를 찾아간다. 그는 우편물 분류 기계를 열었고, 그 안에서 외계인이 엄청난 속도로 편지를 분류하고 있는 모습이 드러난다.
우스꽝스러운 짧은 장면이지만, AI 를 바라보는 데 아주 유용한 시각을 제공해 준다.
무언가를 수신하는 것과 그것을 처리하는 것 사이에는 종종 더 작은 결정이 하나 존재한다. 바로 "이것은 어디에 속하는가?"라는 질문이다.
이 결정을 초반에 정확히 내리면, 시스템의 나머지 부분은 적절한 경로를 따라갈 수 있다.
나는 AI 소프트웨어를 만들면서 이 작은 외계인에 대해 계속 생각해 왔다.
어떤 애플리케이션이 결제 문의, 버그 리포트, 제품 사진, 그리고 데모 예약 요청을 동시에 수신한다고 해보자. 각각은 서로 다른 처리 방식이 필요하다. 그런데도 우리는 결국 동일한 대형 언어 모델에게 모든 것을 검사하고 다음 단계를 판단하도록 맡기곤 한다. 효율적이지도 않고 비용 대비 효과적이지도 않다.
그래서 나는 전문화된 모델들이 AI 의 미래에서 훨씬 더 큰 역할을 할 것이라고 생각한다. 예를 들어, Jev 는 소프트웨어가 즉시 실행할 수 있는 구조화된 의사결정을 위해 설계되었다. Coinbase 는 자사 Onramp 서비스의 사기 탐지를 위해 Qwen3.5-9B 를 특별히 개조했다. 각 모델은 명확히 정의된 하나의 작업에 집중하며, 그 결과는 측정 가능하다.
https://x.com/brian_armstrong/status/2109412046244913643
나는 분류 레이어를 만들고 있다
익숙한 요청은 정해진 워크플로로 곧바로 넘어간다. 더 많은 추론이 필요한 요청은 다른 모델로 전달된다. 모호한 요청은 확인이나 검토를 위해 플래그가 지정된다.
절감 효과는 각 요청에 딱 필요한 만큼의 처리량만 할당하는 데서 나온다. 그런 다음 분류기가 자신의 존재 가치를 증명할 만큼 충분히 정확한 결정을 내리는지 측정해야 한다.
우리의 출발점은 CludeMem이었다. 우리는 AI 가 무엇을 기억해야 하고, 무엇을 검색해야 하며, 무엇이 불필요하게 토큰을 소모하고 있는지 결정하려 했다. 영구적인 선호도, 일시적인 지시, 미해결 질문은 각각 다르게 취급되어야 한다. 이러한 결정을 내리기 전에 먼저 정보를 분류해야 했다.
그것이 더 넓은 범위의 분류 레이어라는 아이디어로 발전했다. 동일한 단계가 지원 요청을 분류하거나, 문서를 라우팅하거나, 어떤 전문가가 작업을 처리할지 선택하는 데 도움을 줄 수 있었다.
GIF
더 많은 전문 모델이 등장할수록, 애플리케이션은 어떤 입력이 자신의 주의를 기울일 만한지 결정해야 한다. 우리가 만들고 있는 것이 바로 이 부분이다. 도착한 것을 분류하고, 익숙한 케이스는 로컬에서 처리하며, 더 어려운 것은 적절한 모델이나 검토 프로세스로 넘기는 것이다.
Clude Cat 을 소개한다 (Cat 은 categorisation(분류)의 약자 😉)
메모리를 저장하거나, 문서를 검색하거나, 도구를 호출하거나, 응답을 생성하기 전에는 보통 우리가 다루고 있는 정보의 종류에 대한 결정이 선행된다.
이러한 결정은 도처에 존재한다.
누군가 소프트웨어 회사에 이렇게 메시지를 보낸다고 상상해 보자.
"내 인보이스는 어디서 다운로드할 수 있나요?"
AI 에이전트는 메시지를 읽고, 사용 가능한 도구를 확인하고, 고객의 의도를 고려한 뒤 인보이스를 찾기로 결정할 수 있다.
더 직접적인 워크플로는 다음과 같을 수 있다.
메시지 → 결제 문서 요청 → 계정 인증 → 인보이스 검색.
답변 작성은 여전히 언어 모델이 담당할 수 있다. 초기 라우팅 결정만 로컬에서 처리하면 된다.
이제 메시지를 바꿔보자.
"결제 금액이 두 번 청구되었고, 계정이 잠겼으며, 해지하고 싶습니다."
이런 내용을 확신을 가지고 단일 인보이스 워크플로로 보내면 오히려 일이 더 커진다. 해결해야 할 문제가 여러 개이며, 올바른 대응을 위해서는 추가 확인이나 사람의 개입이 필요할 수 있다.
분류기에게는 "이것은 확실하게 분류할 수 없습니다"라고 말할 권한이 주어져야 한다.
이는 제품의 필수적인 부분이다. 잘못된 목적지로 요청을 자신 있게 보내는 시스템은, 그 실수를 수정하는 데 드는 작업량 때문에 속도상의 이점을 모두 상쇄해 버릴 수 있다.
고객 입장에서의 기대 효과는 대기 시간과 반복 설명의 감소다.
개발자에게는 검사하고, 테스트하고, 변경할 수 있는 명시적인 결정이 주어진다. 선택된 카테고리, 모델 버전, 처리 시간, 그리고 시스템이 결정을 거부했는지 여부를 모두 확인할 수 있다.
내부적으로 텍스트 구현은 인코더라고 불리는 작은 사전 학습 모델에서 시작된다.
이 모델은 메시지를 의미의 다양한 측면을 나타내는 숫자 목록으로 변환한다. 개발자들은 이를 임베딩이라고 부른다.
"내 인보이스는 어디 있나요?"와 "청구서 사본이 필요합니다"는 사용하는 단어가 다르다. 하지만 수치화된 표현은 시스템이 동일한 종류의 요청임을 인식할 수 있을 만큼 충분히 유사할 수 있다.
분류 레이어는 이러한 표현을 사용해 개발자가 정의한 카테고리에 점수를 매긴다.
우리는 두 가지 접근 방식을 구현했다. 하나는 들어오는 메시지를 각 카테고리의 예시와 비교하는 방식이고, 다른 하나는 레이블이 지정된 예시로부터 카테고리 간의 경계를 학습하는 방식이다.
피팅(fitted) 방식에서는 인코더를 고정 상태로 유지하고 그 위에 더 작은 결정 레이어를 훈련시킨다. 애플리케이션마다 새로운 파운데이션 모델을 훈련시킬 필요가 없다.
여전히 개발자는 각 카테고리가 무엇을 의미하는지 정의하고, 이를 유용한 액션과 연결해야 한다. 분류기가 회사의 부서, 환불 정책, 계정 권한을 스스로 만들어낼 수는 없다.
또한 수용 정책(acceptance policy)도 필요하다.
가장 높은 점수를 받은 카테고리라도 실제로는 적합하지 않을 수 있다. 두 카테고리의 점수가 거의 동점일 수도 있고, 생소한 요청이 익숙한 무언가와 비슷해 보일 수도 있다.
현재 우리의 로컬 점수는 보정된 확률이 아니다. 0.92 라는 점수가 자동으로 "92% 확률로 정확하다"는 뜻은 아니다.
이러한 점수가 결정을 통제할 때 어떤 일이 발생하는지 테스트해야 한다.
따라서 출력은 수용된 카테고리, 검토가 필요한 요청, 기술적 오류를 구분한다. 타임아웃, 취소, 모델 오류 역시 예측 가능하게 처리되어야 한다.
이것이 분류기를 둘러싼 엔지니어링이다. 이는 다른 애플리케이션이 해당 결과를 안전하고 일관되게 사용할 수 있는지를 결정한다.
우리는 이 접근 방식이 생성형 모델의 작업량을 줄일 수 있는지 확인하기 위해 770 개의 은행 업무 요청을 대상으로 실험을 진행했다.
첫 번째 구성은 모든 요청을 로컬에서 실행되는 Qwen2.5 7B 모델로 보내 분류하게 했다.
두 번째 구성은 먼저 로컬 분류기를 사용하고, 해결되지 않은 요청만 Qwen 으로 보냈다.
결과는 다음과 같았다.
- Qwen 호출 횟수가 770 회에서 227 회로 감소했다.
- 정확한 분류 건수가 535 건에서 642 건으로 증가했다.
- 전체 입력에 대한 정확도가 69.5% 에서 83.4% 로 상승했다.
- 측정된 쿼리 시간의 총합이 299.7 초에서 87.7 초로 줄어들었다.
로컬 단계 덕분에 543 회의 Qwen 호출을 피했으며, 이는 70.5% 감소한 수치다.
캐싱은 활성화된 상태였으며, 직접 접근 방식이 결합 접근 방식보다 먼저 실행되었다. 시간 수치에는 설정 및 워밍업 시간이 제외되어 있다. 우리는 최종 고객 답변을 생성하거나 모델 제공업체에 비용을 지불하지 않고 순수하게 분류 과정만을 측정했다.
이 수치들은 해당 구성에 대한 설명일 뿐이다. 모든 LLM 보다 우수하다는 것을 입증하거나 고객의 비용 절감을 증명하는 것은 아니다.
이후 진행된 별도의 실험에서는 24 개의 여행 및 업무 관련 인텐트를 대상으로 피팅된 로컬 분류기를 테스트했다.
720 개의 요청 중 688 개를 로컬에서 수용했다. 그중 681 개는 정확했고 7 개는 틀렸다. 32 개는 검토 대상으로 남겼다.
이를 통해 두 가지 다른 측정값을 얻었다.
- 커버리지: 요청의 95.6% 를 로컬에서 처리했다.
- 수용 정밀도: 수용한 결정 중 99.0% 가 정확했다.
두 지표는 반드시 함께 제시되어야 한다. 분류기는 쉬운 요청 몇 개만 수용하는 방식으로 인상적인 정밀도를 달성할 수도 있기 때문이다.
또한 지원 카테고리 밖으로 벗어나야 하는 100,000 개의 생소한 입력도 테스트했다. 이때 94% 이상의 정확도를 보였다.
시스템이 무엇을 모르는지 인식하는 것 역시 여전히 중요한 작업이다.
속도에도 동일한 주의가 필요하다. 별도의 웜 CPU 테스트에서 M4 Max 기준 전체 은행 업무 분류기는 중앙값 기준으로 요청당 약 1.8 밀리초가 소요되었다. 여기에는 토크나이징, 임베딩, 스코어링이 모두 포함된다.
모델 다운로드 및 구동 시간은 제외되었다. 이는 분류에 걸린 시간이지, 사용자의 전체 요청을 해결하는 데 필요한 시간이 아니다. 또한 스마트폰이나 일반 노트북에서도 동일한 성능이 나온다는 것을 보장하지 않는다.
Jev 가 이 논의에 적합한 이유는 이미 유사한 유형의 의사결정을 다루고 있기 때문이다.
TypeSafe 는 Jev 를 제공된 옵션 중 선택하거나 요청을 일반 코드, 전문 모델, 사람으로 라우팅하는 등 제한된 판단(bounded judgments)을 위한 모델로 문서화하고 있다. \Jev 의 인텐트 라우팅 문서\
내가 생각하는 Jev 의 역할은 로컬 분류기가 안정적으로 해결하지 못하는 요청을 위한 선택적 에스컬레이션 경로다.
우리가 목표로 하는 아키텍처는 간단하다.
수신된 요청 → 로컬 분류 → 익숙한 요청은 정해진 경로로 이동하고, 불확실한 요청은 Jev, 다른 모델 또는 사람의 검토로 넘어간다.
Jev 가 없더라도 동일한 로컬 분류 단계가 해결되지 않은 요청을 애플리케이션의 기존 LLM, 확인 단계 또는 검토 프로세스로 되돌려 보낼 수 있다.
개발자가 카테고리, 수용 임계값, 폴백을 제어한다. 기존 워크플로에 로컬 분류기를 도입하고 어떤 결정을 대신 처리할 수 있는지 측정할 수 있다.
현재 Jev 통합은 섀도우 모드로 작동하며, 애플리케이션의 동작을 변경하지 않고 5 개의 광범위한 주제에 걸쳐 결정을 비교한다. 다음 단계는 선택적 에스컬레이션이 전체 워크플로를 개선하는지 테스트하는 것이다. 위에서 언급한 Qwen 결과는 Jev 의 벤치마크가 아니다.
우리가 측정해야 할 것은 바로 이것입니다. 불필요한 모델 호출 감소, 익숙한 요청의 빠른 처리, 그리고 더 많은 주의가 필요한 사례를 위한 명시적인 경로입니다.
우리는 동일한 접근 방식을 이미지로 확장하기 시작했다.
영수증, 오류 스크린샷, 제품 사진을 수신하는 비즈니스를 상상해 보자. 각각은 다른 처리 경로가 필요하다.
영수증은 영수증 추출로, 스크린샷은 지원 워크플로로, 제품 사진은 카탈로그 워크플로로 갈 수 있다. 불확실한 이미지는 검토로 넘어간다.
분류기가 목적지를 선택한다. 구매 총액 읽기, 오류 진단, 제품 세부 정보 식별은 여전히 별개의 작업으로 남는다.
우리의 실험용 이미지 구현은 사전 학습된 CLIP 인코더를 사용해 이미지의 수치적 표현을 생성한다.
피팅된 연구 후보 모델은 소규모 진단 테스트에서 20 장의 식품 사진 중 19 장을 정확하게 분류했다. 또한 30 장의 콩 잎 이미지를 모두 검토 대상으로 보냈다.
유일한 실수는 병의 영양 성분표와 바코드를 영수증으로 분류한 것이었다.
문제를 알 수 있을 것이다. 둘 다 빽빽한 텍스트, 숫자, 직사각형 레이아웃을 포함할 수 있다. 우리 애플리케이션이 중요하게 여기는 경계를 가르칠 예시가 필요하다.
해당 샘플은 프로덕션 수준의 주장을 하기에 너무 좁다. 레이블은 데이터셋에서 파생된 것이며 독립적으로 판정된 것이 아니었고, 테스트에 새로운 영수증이나 스크린샷 예시는 포함되지 않았다. 공개 데모는 별도의 베이스라인을 사용하므로, 피팅된 후보 모델의 결과를 데모의 성과로 돌려서는 안 된다.
이미지 처리는 텍스트 분류보다 무거웠다. M4 Max 기준 웜 상태의 중앙값 처리 시간은 Node 에서 약 36 밀리초, Chromium 에서 197 밀리초였다. 브라우저는 런타임 외에 약 85 MiB 의 모델 자산을 먼저 다운로드해야 한다.
로컬 실행에도 비용은 발생한다. 다운로드 크기, 메모리, 시작 시간, 기기 성능 모두 평가 대상에 포함되어야 한다.
내가 구상하는 제품은 기존 애플리케이션에 통합되어 다음에 무슨 일이 일어날지 결정하는 역할을 한다.
개발자는 카테고리를 정의하고, 대표적인 예시를 제공하고, 목적지를 연결하며, 분류가 불확실할 때 어떤 일이 일어나야 하는지 선택한다.
첫 배포는 결과물을 변경하지 않고 현재 워크플로를 관찰하는 데 그쳐야 한다. 이후 분류기가 라우팅을 제어하도록 허용하기 전에 제안된 결정과 검증된 결과를 비교할 수 있다.
우리는 거부된 요청만큼이나 수용된 실수도 면밀히 검사해야 한다. 그렇지 않으면 자신 있게 내려진 잘못된 결정이 안심시키는 점수 뒤에 숨어버릴 수 있다.
훈련, 보정, 테스트에도 각각 별도의 데이터가 필요하다. 훈련은 카테고리를 가르친다. 보정은 수용 규칙을 선택한다. 보호된 테스트는 고정된 결과를 확인한다.
테스트에서의 실수가 다음 모델에 영향을 미치는 순간, 그 예시는 개발 데이터가 되어버린다. 다음 평가에는 새로운 테스트가 필요하다.
우편물 분류 기계 속 작은 외계인은 사람들에게 이 작업의 모습을 그려볼 수 있는 방법을 제공한다. 유용한 버전을 만든다는 것은 정확히 어떤 입력을 처리할 수 있는지, 언제 도움을 요청해야 하는지, 그리고 실수의 비용이 얼마인지를 알아내는 것을 의미한다.
다음 단계는 독립적인 레이블과 모든 결과에 대한 기록을 갖춘 대표적인 워크플로를 구축하는 것이다. 얼마나 많은 요청이 로컬 경로를 거치는지, 얼마나 많은 요청이 다른 모델에 도달하는지, 얼마나 많은 것이 잘못되는지, 그리고 이러한 오류를 고려했을 때 전체 애플리케이션이 더 빠르거나 저렴해지는지를 측정해야 한다.
이제 규모를 키우고 이 로컬 모델에 강력한 힘을 더해줄 차례다.
