Jev의 오픈소스 버전, Laya

• Laya는 텍스트를 생성하지 않고 구조화된 결정을 내리는 오픈소스 System 1 모델 제품군임

  • 자동회귀 LLM과 달리 양방향 encoder가 한 번의 forward pass로 분류·점수·확률을 계산함

  • 단일 GPU에서 질문 1개는 P50 32.8ms, 10개 batch는 72.3ms로 질문당 약 7.2ms에 처리함

  • 영어와 100개 이상의 언어를 지원하며 Apache 2.0 가중치로 자체 호스팅 가능함

  • classification, routing, triage, guardrail처럼 답을 생성할 필요 없이 빠르게 결정만 내리는 작업이 주요 대상임

• 생성형 LLM은 단순한 분류·라우팅에도 불필요한 비용과 복잡성을 만들 수 있음

  • 지원 티켓 담당 부서, 스팸·피싱 여부, jailbreak 탐지, 긴급도처럼 답의 범위가 정해진 작업에도 대형 LLM을 호출하는 경우가 많음

  • 토큰 생성에 수백~수천 ms가 걸리고, 자유 형식 응답에서 label을 꺼내기 위한 JSON parser나 regex도 필요함

  • LLM이 생성한 "confidence": 0.95도 실제로 보정된 확률이라고 볼 수 없음

  • Laya는 이런 작업을 30~35ms 수준의 작은 decision model로 분리하는 접근임

• 구조적으로는 Laya가 System 1, LLM이 System 2를 담당함

  • 단순하고 반복적인 판단은 Laya가 바로 처리함

  • 복잡한 추론이나 자연어 생성이 필요한 요청만 LLM으로 넘김

Request
  ↓
Laya
  ├─ 단순하고 확신 높은 결정 → 바로 처리
  └─ 복잡하거나 불확실한 요청 → LLM

• 한 번의 forward pass에서 세 가지 typed question을 평가할 수 있음

  • choice

    • 미리 정의된 후보 중 하나를 선택하고 전체 확률 분포와 confidence를 반환함

  • score

    • 입력을 0, 1, 2... 형태의 순서형 rubric에 배치하고 기대 score와 분포를 반환함

  • noul

    • Yes/No 질문에 대해 0.0~1.0의 P(true)를 반환함

  • 출력 공간이 숫자와 확률로 제한돼 있어 잘못된 JSON이나 schema 위반은 구조적으로 발생하지 않음

  • 다만 출력 형식이 안정적이라는 것과 판단이 항상 정확하다는 것은 별개임

• 용도와 언어에 따라 세 가지 checkpoint를 제공함

• 영어 모델의 confidence만으로는 지원하지 않는 언어를 감지할 수 없었음

  • MASSIVE benchmark에서 영어 전용 ModernBERT-large는 일부 비라틴 언어를 거의 맞히지 못하면서도 confidence는 매우 높게 나왔음

  • Khmer는 accuracy 0.000인데 confidence 0.952, Hebrew는 accuracy 0.060인데 confidence 0.964를 기록함

  • 즉 "confidence가 낮으면 multilingual 모델로 보내자"는 방식으로는 보호할 수 없음

  • forward pass 전에 입력 언어를 보고 어떤 모델을 사용할지 먼저 결정해야 함

• 내장 Router가 문자 체계와 stopword 분포를 분석해 적절한 checkpoint를 자동 선택함

  • Devanagari, CJK Han, Cyrillic, Arabic, Hebrew, Tamil, Thai 등 22개 문자 체계를 검사함

  • routing 오버헤드는 일반 영어 0.09ms, Indic 텍스트 0.54ms, 큰 JSON도 0.73ms 수준임

  • 약 33ms인 모델 실행 시간과 비교하면 2% 미만임

  • Router(preload=True)를 사용하면 checkpoint를 메모리에 미리 올려 언어 전환 시 cold-swap 지연도 피할 수 있음

from laya import Router

router = Router(preload=True)

# 입력 언어에 따라 checkpoint 자동 선택
res = router.predict(state, questions)

# 필요한 경우 특정 모델 지정
res = router.predict(
    state,
    questions,
    model="typed-decisions"
)

• 공개 benchmark에서는 routed Laya가 Jev보다 낮은 latency와 더 나은 calibration을 보였다고 보고함

  • Laya 수치는 프로젝트 측 직접 측정이며, Jev는 제3자 연구와 공개 자료를 사용한 비교임

• 특히 여러 질문을 한 번에 평가할 때 비자동회귀 구조의 장점이 커짐

  • 하나의 ticket에 대해 담당 queue, urgency, churn risk 같은 여러 판단을 한 번의 forward pass로 처리할 수 있음

  • 10개 질문 batch에서는 질문당 약 7.2ms까지 내려감

• 기업 workflow에서도 여러 분류 작업에 적용 가능한 결과를 보였음

  • Enron spam: accuracy 0.993, F1 0.993

  • Phishing: accuracy 0.980, F1 0.979

  • ToxicChat 기반 guardrail: accuracy 0.755~0.762

  • RAG relevance filtering: accuracy 0.657

  • 10개 queue support routing: accuracy 0.522

  • 즉 모든 task를 zero-shot으로 잘 푸는 범용 모델이라기보다 업무에 맞춰 학습·보정해서 사용하는 decision model에 가까움

• 가장 큰 한계는 choice의 후보가 많아질수록 성능이 떨어진다는 점임

  • 77개 label을 사용하는 Banking77에서는 Laya 0.425, Jev 0.870을 기록함

  • 선택지들이 제한된 token 예산을 공유하기 때문에 후보가 많아질수록 각 label을 표현할 공간이 줄어듦

  • choice는 가능하면 20개 이하로 유지하고, 후보가 많다면

    • 먼저 넓은 카테고리를 선택하고

    • 다음 단계에서 세부 항목을 고르는

    • 계층형 분류 구조가 권장됨

• 기본 checkpoint가 모든 문제를 zero-shot으로 잘 해결하는 것은 아님

  • Typed Decisions benchmark에서 별도 fine-tuning이 없으면 accuracy가 약 0.35 수준임

  • 공개된 0.766은 해당 task의 train split으로 fine-tuning한 결과임

  • 즉 범용 zero-shot oracle이라기보다 업무별 fine-tuning을 전제로 한 작은 foundation model에 가까움

• confidence 역시 배포 도메인에 맞춰 calibration하는 것이 중요함

  • 질문 유형별 scalar temperature를 fitting해 calibration 가능함

  • 프로젝트 측 실험에서는 ECE가 0.466 → 0.081로 감소함

  • 실제 서비스에서 confidence를 기준으로 자동 처리, LLM fallback, 사람 escalation 등을 나누려면 accuracy와 함께 calibration을 봐야 함

• 설치와 사용은 일반 Python 패키지처럼 가능함

pip install "laya>=0.3.3"

• 모델·코드·데이터·학습 자료까지 공개

  • 초기 논문과 후속 논문을 공개함

  • Hugging Face에 checkpoint를 제공함

  • 대화형 데모에서 workflow와 multilingual routing을 시험할 수 있음

  • GitHub에 코드와 benchmark harness를 제공함

  • PyPI에서 pip install laya로 설치 가능함

  • Kaggle GPU에서 fine-tuning할 수 있는 notebook도 제공함

• Laya는 LLM 앞단에서 빠르고 반복적인 판단을 담당하는 오픈소스 System 1 계층

^{source https://laya.convaiinnovations.com/}

HN에서는 ‘누가 이 기술을 먼저 생각했는가’보다, 기존 아이디어를 누구나 이해하고 바로 쓸 수 있는 제품으로 만든 역량을 더 높게 평가하는 분위기였다. Laya 개발자가 선행 연구자로서 느낀 좌절감에는 공감하는 반응이 많았지만, 영업 대화에 특화된 기존 연구를 범용 분류기인 Jev의 직접적인 선행 기술로 보기는 어렵다는 반론도 적지 않았다. 비슷한 아이디어와 구현 사례가 이미 여러 차례 등장한 만큼, 논문과 가중치를 먼저 공개했다는 사실만으로 제품의 독창성을 입증하기는 어렵다는 시각이다.

그렇다고 Jev의 마케팅이 그대로 받아들여진 것도 아니다. ‘혁신’이나 ‘환각 없음’을 앞세운 표현에 대해서는, 익숙한 BERT 계열 분류 기술에 새로운 이름을 붙인 것 아니냐는 비판이 나왔다. 다만 제품 경험 자체는 기존 오픈소스 모델과 분명한 차이가 있다. 별도의 학습 과정 없이 여러 분류 작업을 바로 실행하고, 정형화된 출력과 보정된 확률값을 API로 받을 수 있기 때문이다. 개발자가 직접 데이터셋을 만들고 모델을 학습하는 데 며칠을 쓰는 대신 몇 분 만에 기능을 붙일 수 있다면, 기술적으로 완전히 새로운 접근이 아니더라도 충분한 제품 가치는 생긴다.

실제로 Laya와 Jev의 가장 큰 차이는 fine-tuning 필요 여부와 운영 부담에서 드러난다. Laya는 좋은 성능을 내려면 업무에 맞는 데이터로 추가 학습하는 과정이 필요하고, 기본 모델의 성능이나 입력 길이에도 한계가 있다. 실제 사용자 평가에서도 특정 작업에서는 Jev보다 정확도가 크게 낮았다는 경험담이 있었다. 반면 오픈소스 가중치를 직접 호스팅할 수 있다는 점은 데이터 통제와 세밀한 커스터마이징이 중요한 조직에 분명한 장점이다. 대신 GPU 인프라, 학습 데이터 파이프라인, 데이터 분포 변화에 따른 재학습까지 직접 운영해야 한다는 비용도 함께 봐야 한다.