로컬 결정 모델, 한국어 요청 18개 분류에서 Laya는 47~48%, Qwen 기반 0.8B 모델은 71~81% — 같은 문장 한·영 쌍으로 측정

핵심 요약

먼저 알아 둘 용어

측정 방법

데이터 — 같은 뜻의 한국어·영어 문장 쌍

Amazon이 공개한 MASSIVE 1.1(CC BY 4.0)을 썼습니다. 음성 비서에게 하는 짧은 요청을 51개 언어로 옮긴 데이터셋이고, 언어마다 같은 번호의 문장은 같은 뜻과 같은 정답을 갖습니다. 평가용으로 따로 떼어 둔 test 묶음 2,974쌍에서 한국어와 영어의 정답이 모두 일치하는 것을 확인했습니다. 한국어 문장은 직역이 아니라 현지화돼 있어서, 영어 “can you book an uber for me”가 한국어로는 “카카오택시 예약 좀 해줄래”입니다.

과제는 요청을 18개 영역(scenario) 중 하나로 고르는 것입니다. 알람, 음량, 일정, 요리, 날짜·시간, 이메일, 잡담, 스마트홈(iot), 목록, 음악, 뉴스, 재생, 상식 질문(qa), 추천, 소셜, 배달 음식, 교통, 날씨입니다. 영역마다 30문장을 매번 같은 결과가 나오도록 고정한 난수로 뽑아 540쌍을 만들었으므로, 무작위로 고르면 정답률은 약 5.6%(18분의 1)입니다. 느린 디코더 계열 모델은 이 가운데 영역마다 앞의 10문장, 즉 180쌍으로만 실행했고, 모델끼리 비교할 때는 Laya도 같은 180쌍 기준으로 다시 집계했습니다.

조건 세 가지

질문은 선택형(choice) 하나였습니다. 예를 들어 한국어 + 한국어 라벨 조건의 요청 본문은 이렇습니다(선택지는 18개 중 둘만 옮겼습니다).

{"model": "laya:multilingual",
 "state": "오전 다섯 시 에 깨워줘",
 "questions": {"domain": {"type": "choice",
   "instructions": "이 사용자 요청은 스마트 비서의 어느 영역에 해당합니까?",
   "criteria": {"alarm": "알람 설정, 확인, 취소",
                "iot": "스마트홈 기기 제어: 조명, 플러그, 커피 머신, 로봇 청소기", …}}}}

18개 영역의 라벨 설명은 각 영역에 속한 MASSIVE 세부 의도(intent) 이름, 예를 들어 알람이면 set·query·remove를 보고 제가 썼습니다. 설명을 어떻게 쓰느냐에 따라 결과가 달라지므로 7절과 11절에서 다시 다룹니다.

모델과 실행 환경

Ollaya 0.7.2(2026-09-26 릴리스)의 macOS 바이너리를 체크섬 확인 후 설치 없이 임시 폴더에서 실행했고, 모델 가중치는 Ollaya가 고정한 각 개발자의 Hugging Face 커밋에서 받았습니다. 하드웨어는 Apple M1 Max, 메모리 32GB입니다. 요청은 한 번에 하나씩 보냈고, 여러 요청을 묶어 처리하는 배치 실행은 쓰지 않았습니다. 이 글의 모델 중 맥의 GPU에서 실행되는 것은 Laya뿐이고, 디코더 계열은 CPU에서 32비트 부동소수점(fp32)으로 실행됩니다. Ollaya의 실행 상태 조회(/api/ps)가 Laya 두 모델은 metal, 디코더 계열은 cpu로 표시했습니다.

같은 문장, 언어만 바꾸면 — Laya 540쌍

540쌍, 18개 분류, 무작위 기준 5.6%. 95% 신뢰구간은 문장을 다시 뽑았을 때 정확도가 움직일 수 있는 범위로, 비율에 쓰는 Wilson 방식으로 계산했습니다. Ollaya의 laya 라우터에 보내면 영어 540문장은 모두 laya:en(첫 행)으로 라우팅됐고, 한국어는 536문장이 laya:multilingual로, 4문장이 laya:en으로 라우팅됐습니다. 라우터를 거친 한국어 정확도는 47.0%(영어 라벨)로 셋째 행과 같았습니다.

• 같은 모델에서 언어만 바꾸면 약 10%p 떨어졌습니다. laya:multilingual이 영어에서 맞히고 한국어에서 틀린 문장이 112개, 반대가 59개였습니다. McNemar 검정의 p값이 약 0.00006이라 우연한 차이로 보기 어렵습니다.
• 라우터가 실제 사용에서의 차이를 더 벌립니다. 영어는 더 정확한 laya:en(63.1%)으로 가고 한국어는 laya:multilingual(47.0~48.1%)로 가므로, 같은 서비스에서 영어 사용자와 한국어 사용자가 받는 정확도는 15~16%p 차이 납니다.
• 영문 단어가 섞인 한국어는 영어 모델로 갈 수 있습니다. 라우터가 laya:en으로 보낸 한국어 4문장은 “beatles 노래 재생해줘”, “pizza hut 배달 가능하나요”, “locality 뜻”처럼 영문 단어가 들어간 문장이었습니다. 라우터가 밝힌 이유는 “라틴 문자이고 언어를 식별하지 못해 기본값(영어)을 쓴다”였습니다.
• 영어 모델에 한국어를 넣으면 정확도가 크게 떨어집니다. 12.4%입니다. 그런데 확신도 0.9 이상으로 답한 것도 5.2% 있었고 그중 61%가 틀렸습니다. Laya 개발사도 영어 모델이 한글처럼 라틴 알파벳이 아닌 문자에서 “자신 있게 틀린다”고 적어 두었습니다. 라우터를 끄고 모델 이름을 직접 지정할 때 조심해야 하는 이유입니다.
• 라벨 설명을 한국어로 바꾸면 정확도는 거의 같았지만(47.0% → 48.1%, p=0.66), 확신도를 믿을 수 있는 정도가 달라졌습니다. 이 부분은 6절에서 봅니다.

MASSIVE 한국어 문장에는 “오전 다섯 시 에 깨워줘”처럼 조사 앞에 공백이 들어간 곳이 540개 중 81개 있습니다. 이 공백을 없애고 다시 실행해도 정확도는 47.0%, 48.1%로 같았습니다.

모델 6종 비교 — 180쌍

180쌍(영역마다 10문장)만 쓴 결과라 각 값은 문장을 다시 뽑으면 대략 ±6~7%p 움직일 수 있습니다(95% 신뢰구간). 유의성은 같은 문장의 영어·한국어 정답 여부를 짝지은 McNemar 검정입니다. Laya 두 모델의 값이 4절과 조금 다른 것은 540쌍 중 이 180쌍만 센 값이기 때문입니다.

• Qwen3.5 기반 0.8B급 세 모델은 한국어에서 70.6~80.6%로, 같은 문장·같은 조건의 Laya(45.6~49.4%)보다 21~31%p 높았습니다. 카드에 지원 언어를 영어로만 적은 decider와 kev도 한국어를 잘 처리했습니다. 기반인 Qwen3.5가 다국어로 학습된 LLM이기 때문으로 보이지만, 이 측정만으로 원인을 가를 수는 없습니다.
• 언어 격차도 작았습니다. kev와 decision은 영어와 한국어의 차이가 통계적으로 유의하지 않았습니다. decider:0.8b는 영어 라벨일 때 7%p 떨어졌고(p=0.015), 한국어 라벨이면 격차가 2.8%p로 줄었습니다.
• 라벨 언어의 효과는 모델마다 방향이 달랐습니다. decider:0.8b와 kev는 한국어 라벨에서 4%p 넘게 올랐고, decision은 오히려 2.7%p 내렸습니다. 모두 유의하지 않은 차이라 “한국어 라벨이 정확도를 올린다”고 일반화할 수 없습니다.
• decider(2B)는 영어 88.9%, 한국어 + 한국어 라벨 83.9%로 가장 높았습니다. 두 언어의 차이(5%p)는 p값이 0.06으로, 보통 쓰는 0.05 기준으로는 유의하지 않았습니다. 다만 이 맥에서 요청마다 수 초가 걸려(9절) 한국어 + 영어 라벨 조건은 실행하지 않았습니다.

확신도 기준으로 걸러 쓸 때

결정 모델을 실제로 쓰는 방식은 보통 이렇습니다. 확신도가 임계값 이상이면 자동으로 처리하고, 아니면 사람의 검토나 더 큰 LLM으로 보냅니다. 그래서 중요한 것은 전체 정확도보다 임계값을 넘은 답이 얼마나 맞는가와 그런 답이 전체의 몇 %인가입니다.

• Laya에서는 라벨 설명의 언어에 따라 확신도를 믿을 수 있는 정도가 달라졌습니다. 한국어 입력에 영어 설명을 주면 “0.9 이상”이라고 답한 것 넷 중 하나가 틀렸고, 한국어 설명을 주면 열 중 하나 미만이 틀렸습니다. 임계값을 넘는 비율은 28.7%에서 25.2%로 조금 줄었습니다. 개수로는 영어 설명일 때 155개 중 117개, 한국어 설명일 때 136개 중 125개가 맞았습니다. 두 묶음은 임계값을 넘은 문장이 서로 달라 엄밀한 짝 비교가 아닌 탐색적 비교이지만, 두 비율을 비교하는 z 검정으로는 p값이 0.001보다 작았습니다.
• 임계값 0.9가 뜻하는 바는 모델마다 전혀 다릅니다. kev는 0.9 이상인 답이 8~12%뿐이지만 전부 맞았고, decider:0.8b는 절반 이상이 0.9를 넘으면서도 95% 이상 맞았습니다. kev에 0.9를 걸면 90% 넘게 사람에게 넘어가고, decider:0.8b에 걸면 절반 넘게 자동 처리됩니다. Ollaya 문서도 한 모델에서 정한 확신도 기준값을 다른 모델에 그대로 쓰지 말고 모델마다 따로 정하라고 안내합니다.
• 자동 처리 비율로 보면 차이가 더 커집니다. 한국어 라벨 조건에서 확신도 0.9 이상이면서 맞은 답은 decider:0.8b가 전체의 약 61%, Laya가 약 23%였습니다(제가 표의 두 값을 곱한 값입니다).

오답이 몰리는 곳

Laya는 판단이 어려운 문장을 한 라벨로 몰아 분류했습니다. 540문장 중 스마트홈(iot)이 정답인 것은 30개인데, laya:multilingual은 영어에서 177개, 한국어 + 영어 라벨에서 192개, 한국어 + 한국어 라벨에서 158개를 iot로 답했습니다. 예측의 약 30%가 한 라벨에 몰린 것입니다. 같은 180문장으로 세면 Laya는 한국어에서 55~73개(31~41%)를 iot로 답했고, 디코더 계열 세 모델은 12~38개(7~21%)였습니다.

영어 입력 + 영어 라벨, 한국어 입력 + 영어 라벨 조건의 laya:multilingual 결과에서 옮겼습니다.

이 쏠림에는 제가 쓴 iot 설명(“조명, 플러그, 커피 머신, 로봇 청소기 제어”)이 넓었던 영향도 있을 수 있습니다. 스피커 음량 조절은 기기 제어로도 읽힙니다. 다만 같은 설명을 받은 디코더 계열은 대부분 맞혔습니다. 실무에서 쓸 수 있는 신호는 이것입니다. 예측 분포를 세어 봤을 때 한 라벨이 정답 비율보다 몇 배 많이 나오면, 그 라벨 설명을 좁히거나 모델을 바꿀 때라는 뜻입니다.

영역별로 보면 한국어 + 한국어 라벨 조건에서 Laya가 특히 약했던 곳은 잡담(0%), 일정(10%), 추천(10%), 재생(20%), 소셜(20%)이었습니다(180쌍, 영역당 10문장). 같은 영역 가운데 재생을 뺀 네 영역에서 디코더 계열 세 모델은 50~80%를 맞혔습니다. 재생(play)은 모든 모델이 20~40%로 약했고, 틀린 답은 주로 스마트홈(iot)과 음악(music)으로 갔습니다.

개발사가 공개한 숫자와 비교

영어권에서는 Laya를 비판적으로 분석한 글이 먼저 나왔습니다. OrcaRouter 블로그는 모델 카드의 typed-decisions 수치를 근거로 “내려받은 그대로의 Laya는 최다 라벨 기준선보다 무작위에 더 가깝다”고 정리했습니다. 이 글의 과제에서는 그 벤치마크와 달리 Laya가 최다 라벨 기준선(가장 흔한 라벨 하나만 계속 고를 때의 정확도, 이 표본에서는 5.6%)을 크게 넘었습니다. 과제에 따라 결과가 크게 달라진다는 뜻입니다.

맥에서의 속도

모든 측정이 끝난 뒤 다른 작업이 없는 상태에서 모델마다 한국어 요청 30개를 하나씩 보내 다시 측정했습니다(laya:en만 영어 요청). “처리 시간”은 Ollaya가 응답에 적어 주는 모델 내부 시간(토큰화·계산·보정)이고, “첫 요청”은 모델을 메모리에 올리는 시간이 포함된 값입니다.

• 맥에서는 Laya만 GPU를 씁니다. Ollaya 홈페이지는 맥에서 “Laya and NLI on MLX”라고 적고 있고, 실제로 /api/ps도 Laya만 metal로 표시했습니다. 디코더 계열은 ONNX Runtime으로 CPU에서 fp32로 실행됩니다. 그래서 0.8B급 디코더 계열이 laya:multilingual보다 45~79배 느렸습니다. Ollaya가 공개한 RTX 4090 수치에서는 이 차이가 16~23배(Laya 8.1~9.6ms 대 decider 155~190ms)입니다.
• 여러 모델을 한 맥에서 동시에 실행하면 오히려 느려졌습니다. 디코더 계열 세 모델을 동시에 실행했을 때 요청당 6~9초, 2B는 65초까지 늘어 처리량이 순차 실행보다 낮았습니다. 그래서 이 글의 정확도는 모델을 하나씩 순서대로 실행해 다시 측정했습니다.
• 초당 요청이 많은 실시간 분류라면 맥 CPU에서 실행되는 디코더 계열로는 감당하기 어렵습니다. 반대로 밤사이 문의 수천 건을 분류하는 배치 작업이라면 1~2초도 충분히 쓸 만합니다. 첫 요청은 모델을 올리느라 6~36초가 걸리므로, 서버를 띄울 때 미리 한 번 불러 두는 편이 좋습니다.

도입 전에 확인할 것

1. 한국어 입력이 다국어 모델로 가는지 확인하세요. Ollaya의 /api/decide 응답에는 실제로 답한 모델(model)과 라우팅 이유(routing)가 들어 있습니다. 영어 모델에 한국어가 들어가면 12.4%로 떨어지면서도 일부는 높은 확신도로 틀립니다. 영문 브랜드명이 자주 섞이는 서비스라면 라우터 대신 laya:multilingual을 직접 지정하는 편이 안전합니다.
2. 라벨 설명을 입력과 같은 언어로 쓰세요. Laya에서는 정확도는 그대로였지만 확신도 0.9 이상 오답이 38개에서 11개로 줄었습니다. 디코더 계열에서는 효과가 모델마다 달랐으니 두 방식을 모두 측정해 보세요.
3. 자기 데이터 200~500건에 정답을 달아 먼저 측정하세요. 이 글처럼 영역마다 같은 수를 뽑으면 한 라벨로 쏠리는 현상이 바로 보입니다. 모델 카드의 숫자는 과제가 다르면 옮겨지지 않습니다.
4. 예측 분포를 세어 보세요. 한 라벨이 정답 비율보다 몇 배 많이 나오면 그 라벨 설명이 너무 넓거나, 모델이 불확실한 문장을 그 라벨로 분류하고 있다는 뜻입니다.
5. 확신도 임계값은 모델마다 새로 정하세요. 같은 0.9를 넘은 답이 kev는 8~12%, decider:0.8b는 49~63%였습니다. 원하는 정확도를 먼저 정하고, 그 정확도가 나오는 가장 낮은 임계값을 자기 데이터에서 찾으면 됩니다.
6. 지연 예산을 먼저 정하세요. 요청마다 100ms 안에 답해야 한다면 맥에서는 Laya뿐이고, 한국어 정확도는 절반 수준을 감수해야 합니다. Ollaya가 공개한 RTX 4090 수치로는 디코더 계열도 요청당 155~190ms입니다.
7. 모델 카드에서 학습 데이터를 확인하세요. 평가에 쓸 공개 데이터셋이 학습에 들어갔다면 그 점수는 부풀려져 있습니다. decider 카드처럼 카드 안에서 표기가 엇갈리는 경우도 있습니다.
8. 버전을 고정하세요. Ollaya는 저장소가 생긴 지 사흘 만에 0.7.2까지 나왔고, 모델도 며칠 간격으로 새 버전이 올라옵니다. Ollaya는 가중치를 개발자 저장소의 특정 커밋으로 고정하므로, 운영에서는 그 커밋을 기록해 두세요.

아직 결론이 아닌 것

• 과제가 하나뿐입니다. 짧은 음성 비서 명령을 18개 영역으로 분류하는 문제 하나만 측정했습니다. 긴 고객 문의, 예/아니오 판정(noul), 점수형(score) 질문, 선택지가 수십 개인 문제에서는 결과가 다를 수 있습니다. Laya 개발사는 기본 설정에서 선택지가 20개를 넘으면 약해진다고 밝혔습니다(이 글은 18개).
• 라벨 설명은 제가 썼습니다. 설명을 바꾸면 결과가 달라집니다. 특히 iot로의 쏠림은 설명 문구의 영향일 수 있고, 설명을 다듬는 실험은 하지 않았습니다(평가 데이터에 맞춰 설명을 고치면 점수가 부풀려지기 때문입니다).
• 디코더 계열은 180쌍입니다. 값마다 ±6~7%p의 불확실성이 있어, 디코더 계열 모델끼리의 순위는 이 측정으로 정할 수 없습니다. 확실히 말할 수 있는 것은 디코더 계열 세 모델이 모두 같은 문장에서 Laya보다 높았다는 것입니다.
• 평가에 쓴 문장이 학습 데이터에 섞였을 가능성이 있습니다. decider 카드의 MASSIVE 표기가 엇갈리고, 다른 모델도 MASSIVE를 학습에 썼는지 모두 확인하지는 못했습니다. MASSIVE 영어 문장이 학습에 들어갔다면 영어 점수는 부풀려졌을 수 있습니다. 한국어 문장까지 들어갔는지는 확인할 수 없었습니다.
• 한국어 문장은 번역·현지화된 문장입니다. 실제 한국어 사용자가 쓰는 문장과 말투·길이가 다를 수 있습니다. 조사 앞 공백 문제는 Laya에서 결과를 바꾸지 않았지만 다른 모델에서는 확인하지 않았습니다.
• 속도는 이 맥 한 대의 값입니다. M1 Max, 요청 하나씩, 배치 없음. NVIDIA GPU나 다른 CPU에서는 크게 달라집니다. 정확도는 장치에 따라 크게 달라지지 않아야 하지만, 계산 정밀도가 다르면(예: CUDA의 fp16) 확률이 거의 같은 경우 답이 바뀔 수 있다고 Ollaya 문서가 적고 있습니다.
• Jev는 측정하지 않았습니다. TypeSafe API 키 없이 로컬 모델만 측정했습니다. decider 4B, kev 4B·9B, Winnow처럼 더 큰 모델도 이 맥에서 시간이 오래 걸려 제외했습니다.
• 문장 표본은 한 번만 추출했습니다. 결정 모델은 무작위 샘플링 없이 답하므로 같은 입력에는 같은 답이 나옵니다(라우터를 거쳐 다시 보낸 536문장이 모두 같은 답과 확신도를 냈습니다). 다만 문장을 다시 뽑으면 값이 몇 %p 움직일 수 있습니다.

참고자료

1차 출처와 모델 카드는 2026-09-27에 확인했습니다. 측정 스크립트는 MASSIVE test 분할에서 영역마다 30문장을 고정 시드(20260927)로 뽑아 Ollaya의 /api/decide에 한 건씩 보낸 것이 전부입니다.

Ollaya와 모델들은 며칠 간격으로 새 버전이 나오고 있습니다. 이 글의 수치는 Ollaya 0.7.2와 2026-09-27 기준 모델 커밋의 값입니다.