Laya 해설: 단 하나의 토큰도 쓰지 않고 답하는 의사 결정 모델

Laya에 대해 가장 흥미로운 점은 속도가 아니다. 그것은 당신이 Laya에 제공하는 모든 선택지가 각자의 [MASK] 토큰에서 채점되고, 확률은 그 단일 질문의 선택지들에 대해 소프트맥스된다는 점이다. Convai Innovations는 2026년 9월 18일 Hugging Face에 Laya의 가중치를 Apache 2.0으로 공개했다 — 세 개의 체크포인트, 하나의 저장소, 영어 모델 기준 4억 2,100만 개의 파라미터. 출력 토큰은 없다. 디코딩 루프도, 파싱할 JSON도, 닫는 것을 잊을 중괄호도 없다. 상태 하나와 타입이 지정된 질문 집합을 넘기면, 한 번의 순방향 패스 후에 명명된 선택지 중 하나에 대한 선택, 기대 등급이 딸린 서수 점수, 또는 어떤 명제가 참일 확률을 얻는다. 이 설계에는 사람들이 놓치는 귀결이 따른다: 답변 공간이 어휘 헤드에 미리 박혀 있는 것이 아니라 요청마다 조립되기 때문에, 오늘 오후에 당신이 고안한 스키마에는 재훈련이 필요 없다. 한계도 있으며, 프로젝트는 자체 모델 카드에서 이를 분명히 밝힌다: 기본 체크포인트는 typed-decisions 벤치마크에서 0.362점으로, 무작위 추측의 0.318, 항상 다수 클래스로 답하기의 0.461과 대비된다. Convai 자신의 문장이 바로 머릿속에 새겨둬야 할 문장이다 — "Laya는 특화하기 위한 빠른 기반이지, 제로샷 의사결정 엔진이 아니다." 당연한 비교 대상은 TypeSafe AI의 Jev로, 공개된 가중치도, 공개된 파라미터 수치도, 공개된 베이스 모델도 없는 호스팅형 System One 모델이다. Laya는 이에 대한 오픈 가중치 답변이다. 그 답변이 당신에게 유용한지는 거의 전적으로 당신이 파이프라인의 어느 절반을 대체하려는지에 달려 있다.

Laya가 실제로 무엇인지, 그리고 무엇이 아닌지

부정적인 것부터 시작하자. 대부분의 글이 잘못되는 지점이 바로 거기이기 때문이다. Laya는 LLM이 아니다. Laya는 비자기회귀적이다. 단일 순전파가 답을 만들어 내며, 모델은 텍스트를 전혀 출력하지 않는다. Laya의 지연 시간을 채팅 모델의 초당 토큰 수와 비교하는 것은 서로 다른 두 가지 연산을 비교하는 것이다. 하나는 분류하고, 다른 하나는 생성한다. 문단, 요약, 계획, 또는 추론 연쇄가 필요하다면, Laya는 그것을 줄 수 없고 주려고도 하지 않는다.

무엇인가: 위에 결정 헤드를 붙인 양방향 인코더입니다. 영어 체크포인트는 ModernBERT-large — 395M 매개변수, 완전히 미세 조정됨 — 에 두 개의 트랜스포머 레이어, 옵션 마커 스코어러, act/escalate 헤드로 구성된 처음부터 훈련된 헤드를 더한 총 421M입니다. 다국어 체크포인트는 백본을 mmBERT-base로 교체하며, 22개 레이어와 256k 어휘로 총 322M입니다. 세 개의 체크포인트가 하나의 저장소에 포함되어 제공되며, 요청한 것만 다운로드됩니다:

• convaiinnovations/laya — ModernBERT-large, 4억 2,100만 개 파라미터, 512토큰 컨텍스트, 영어, 디스크상 약 808MB.

• convaiinnovations/laya-multilingual — mmBERT-base, 3억 2,200만 개 파라미터, 1,024 토큰 컨텍스트(RoPE를 사용하면 인코더가 최대 8,192까지 지원), 100개 이상의 언어, 약 2.2배 더 빠름, 약 647 MB.

• convaiinnovations/laya-typed-decisions — ModernBERT-large, 4억 2,100만 개 파라미터, 1,024 토큰 컨텍스트를 갖추고 있으며, 세 모델 중 어디에서나 인용되는 0.766이라는 수치를 지닌 유일한 모델입니다.

A Router는 앞단에 위치하여 요청마다 순수 Python으로 0.5밀리초 이내에 문자 체계와 언어를 감지해 체크포인트를 선택하며, 이는 어떤 포워드 패스가 일어나기 전에 이루어집니다. 그것은 편의 기능이 아닙니다. 정확성 기능이며, 프로젝트 자체의 증거가 그 이유를 보여줍니다: 영어 체크포인트는 크메르어에서 정확도 0.000을 기록하면서도 신뢰도 0.952를 보고합니다. 완전히 틀리면서도 계속 확신하는 모델은 바로 신뢰도 게이팅이 구해줄 수 없는 경우이므로, 라우팅 결정은 모델이 입력을 보기 전에 내려져야 합니다. 51개 언어 스윕 전반에서 라우터는 51개 언어 중 45개를 사용 가능하게 만들었습니다 — 무작위 대비 3배를 능가하는 것으로 정의됨 — 반면 영어 체크포인트 단독으로는 51개 중 23개에 그쳤습니다.

이해할 가치가 있는 설계상의 사실: 각 옵션당 하나의 [MASK] 토큰

이 글에서 하나만 가져간다면, 이것만은 가져가세요. 일반적인 분류 헤드에서는 레이블 집합이 학습 시점에 고정됩니다: 최종 레이어는 클래스마다 출력 하나를 가지며, 클래스를 추가하려면 재학습해야 합니다. Laya는 그렇게 하지 않습니다. 각 옵션을 마커가 있는 텍스트로 렌더링하고, 옵션 마커 스코어러는 해당 옵션 자체의 [MASK] 위치에서 점수를 읽습니다. 그런 다음 해당 질문에 속한 옵션들에 걸쳐 소프트맥스를 적용합니다.

따라서 답변 공간은 요청 시점에 정의됩니다. 당신이 선택지를 작성하면, 모델이 점수를 매깁니다. 새로운 스키마는 재훈련이나 미세 조정이 필요하지 않습니다. 왜냐하면 가중치에는 "청구"나 "기술"을 클래스로 인코딩하는 것이 없기 때문입니다 — 오직 상태의 맥락에서 렌더링된 한 선택지를 다른 선택지와 비교하는 메커니즘만 있을 뿐입니다.

그 작동이 얼마나 잘 되는지는 두 예산에 의해 좌우되며, 그 예산은 공유됩니다. 각 시퀀스는 옵션 프롬프트 예산(head_max_len, 영어 체크포인트에서는 192토큰, 나머지 두 개에서는 256토큰)과 문서 예산(max_len의 남은 부분). 한 호출의 모든 질문은 동일한 단일 포워드 패스에서 답변되므로, 질문이 여섯 개인 호출이 여섯 번의 모델 호출인 것은 아닙니다. 그러나 옵션들은 옵션 예산을 공유합니다. 그래서 Banking77처럼 옵션이 77개인 질문은 레이블당 대략 3~4토큰을 할당하고 정확도가 급락합니다 — Jev가 공개한 0.870에 비해 0.425입니다. 해결책은 숨겨진 것이 아니라 문서화되어 있습니다: head_max_len과 max_len을 높이거나, 큰 옵션 집합을 2단계 coarse-to-fine 선택으로 나누는 것입니다.

세 가지 프리미티브

Laya가 수행하는 모든 것은 세 가지 질문 유형 중 하나이며, 각각은 서로 다른 형태를 반환합니다:

• choice — 이름이 지정된 각 옵션에 대한 확률, 그리고 최상위 레이블과 신뢰도. 이것은 라우팅 및 의도 분류 프리미티브입니다.

• 점수 — 정렬된 평가 기준표에 대한 분포와 예상 수준. 이것은 순서형 기본 요소입니다: 긴급도, 좌절감, 심각도.

• noul — 진술이 참일 확률을 0.0에서 1.0 사이로 보정한 값입니다. 피싱, 이탈 위험, 프롬프트 인젝션.

타입은 운영상 중요한 방식으로 엄격합니다. 선택형 질문은 제공하지 않은 선택지를 반환할 수 없습니다. 왜냐하면 점수를 매길 수 있는 선택지는 렌더링한 것뿐이기 때문입니다. 이는 한 부류의 프로덕션 실패를 제거합니다 — 만들어낸 enum 값, 잘린 JSON, 파서를 둘러싼 재시도 루프. 하지만 의미상 오류는 제거하지 않습니다. 한 모델이 반환합니다: 기술 지원으로 가야 했던 티켓에 대해 billing: 0.94. 이는 잘못되었고, 자신 있게 잘못되었습니다. 타입이 지정된 출력은 답의 형태를 보장할 뿐, 결코 정확성을 보장하지 않습니다.

RLCD, 또는 확률이 무언가를 의미해야 하는 이유

대부분의 분류기는 정답을 내도록 훈련된다. Laya는 자신이 얼마나 맞는지에 대해 솔직하도록 훈련되며, 그 바탕은 훈련 레시피에 있다.

이 방법은 RLCD — Reinforcement Learning for Calibrated Decisions(보정된 결정을 위한 강화학습)라고 부른다. 정책은 argmax가 아니라 분포를 출력하고, 탐험은 로짓에 평균이 0인 가우시안 노이즈를 더하며, 보상은 엄격히 적절한 스코어링 규칙이다 — 로그에 구면(spherical)을 더한 형태이고, 순서형 질문에는 순위 확률 점수(ranked probability score)를 추가한다. 바로 그 "proper"라는 단어가 핵심 역할을 한다. 엄격히 적절한 스코어링 규칙은 자신의 진짜 믿음을 보고할 때만 기대값에서 최대화되므로, 애매하게 말하거나 과대 주장하는 것은 지침이 아니라 구조상 보상을 잃는다. 업데이트는 그룹 평균 베이스라인을 둔 REINFORCE이며 GRPO 스타일이고, 다중 턴 대화는 프리픽스 슬라이스에 대해 TD(λ=1.0)를 사용한다.

실질적인 결과는 신뢰도 임계값이 애플리케이션 로직을 구축하는 데 의미 있는 요소라는 점입니다 — 이는 교차 엔트로피로 학습된 분류기의 소프트맥스에 대해서는 할 수 없는 주장입니다. 또한 이 프로젝트가 솔직히 밝히는 주의사항이 있는 주장이기도 합니다: 제공되는 체크포인트는 과도하게 확신하며, 숫자를 신뢰하기 전에 자신의 데이터로 온도를 재적합할 것으로 기대됩니다. 질문 유형과 옵션 수당 하나의 온도를 재적합한 결과, 영어 체크포인트에서 평균 ECE가 0.466에서 0.081로, 다국어 체크포인트에서 0.314에서 0.106으로 이동했습니다. 자동 승인 대 인간 검토를 위한 프로젝트의 제안 시작 임계값은 약 0.85입니다.

운영하는 데 드는 비용

지연 시간 수치는 프로젝트 자체 측정치이며, 모든 체크포인트가 동일한 실행에서 바이트 단위로 동일한 질문에 답하는 가운데 Tesla T4에서 측정한 것입니다:

• 질문 하나 — 39.5 ms (laya), 32.8 ms (laya-multilingual).

• 다섯 가지 질문 — 84.5ms 및 40.1ms.

• 질문 10개 일괄 처리 — 158.6ms(질문당 15.9ms) 및 72.3ms(질문당 7.2ms).

• 질문 50개 — 771ms 및 337ms, 즉 다국어 체크포인트에서 질문당 6.8ms.

• 단일 T4에서의 배치 처리량 — 초당 103~332개 질문.

“Jev보다 50배 빠르다”라는 주장이 돌고 있는 것을 보셨다면, 그것은 이 프로젝트의 수치가 아니며 프로젝트 자체의 벤치마크도 이를 뒷받침하지 않습니다. Convai가 공개한 비교는 한 질문에 대한 p50 지연 시간 기준 7.8배입니다: 32.8ms 대 236–276ms. 그 비교 역시 주의 깊게 읽어야 할 대상인데, Laya의 카드가 Jev 쪽을 Convai가 결코 측정한 적 없는 제3자 공개 수치로 표시하고 있고 — Convai에는 TypeSafe API 접근 권한이 없습니다 — 또한 로컬 GPU 순전파를 네트워크 왕복과 큐잉을 포함하는 호스팅 API 호출과 맞세우기 때문입니다. 그 격차의 아키텍처적 부분은 실재합니다. 그 격차의 인프라적 부분은 모델의 속성이 아닙니다.

메모리 측면에서 체크포인트당 사용량은 수백 메가바이트이며, 호스트 규모를 산정하기 전에 배포 표를 알아두면 좋습니다. 지연 로딩(lazy) 기본 설정은 두 개의 체크포인트(영어와 다국어, 라우터가 자동으로 선택하는 유일한 두 가지)를 상주시킵니다. 따라서 각 언어를 처음 로드한 이후에는 전환 시 감지 비용만 발생합니다. 메모리가 제한된 환경에서 Router(max_loaded=1)는 언어를 전환할 때마다 다시 로드하며, 측정값은 CPU에서 중앙값 7.4초, T4에서 10.3초입니다. Router(preload=True)는 서버 구성입니다. 아무것도 다시 로드하지 않으며, 요청당 지연 시간은 GPU 기준 32.8ms, CPU에서 193–464ms입니다.

정직한 절반

바로 이 대목에서 이 글의 진가가 드러난다. Laya 주변의 표면은 요란하고 한계는 구체적이기 때문이다.

첫째, 헤드라인 숫자는 미세 조정된 숫자입니다. 0.766 정확도는 laya-typed-decisions, 즉 해당 벤치마크 자체의 훈련 분할로 미세 조정된 체크포인트에 속합니다. 기본 체크포인트들은 0.318 무작위 기준선과 0.461 다수 클래스 기준선 대비 제로샷으로 0.362와 0.342를 기록합니다. 다시 말해, 자명한 기준선보다 낮습니다. 프로젝트는 이를 묻어두기보다 자체 한계 목록에서 그렇게 밝히고 있으며, 미세 조정된 체크포인트는 0.735의 교사 자기 일치도 상한을 넘어섭니다. 이는 네 가지 좁은 워크플로(송장 처리 0.804, 보안 사고 0.766, 고객 서비스 0.764, 에이전트 트레이스 관측성 0.730)에서 421M 인코더치고는 진정으로 강력한 결과입니다. 하지만 이것은 특화에 관한 결과이지 기본 모델에 관한 결과가 아니며, 0.766을 일반적 역량으로 인용하는 사람은 모델 카드를 잘못 읽는 것입니다.

둘째, 프리미티브들은 똑같이 좋지 않습니다. 파인튜닝된 체크포인트에서의 정확도 기준으로: noul 0.857, choice 0.733, score 0.723. 프로젝트는 서수형 score를 "가장 약한 프리미티브"라고 단호히 부릅니다. SST-5는 0.372입니다. 만약 당신의 의사 결정 표면이 1~5 심각도 등급이라면, 그것은 당신이 기본 설정으로 가장 신뢰할 이유가 적은 프리미티브입니다.

셋째, 두 가지 동작이 프로젝트 자체 이슈 트래커에 버그로 문서화되어 있으며, 둘 다 읽지 않으면 프로덕션에서 큰 문제를 일으킬 것입니다. action.act_probability는 아직 쓸 만한 신호를 담고 있지 않습니다 — 이슈 #185 — 의사 결정 헤드의 출력이 인코더 스케일의 약 300배로 정규화되지 않아 act 헤드가 포화되어 거의 모든 입력에 대해 1.0으로 읽히기 때문입니다. 그 원시 로짓은 정확성에 역행하여, 레이블이 지정된 396개의 결정에서 AUROC가 0.30입니다. 대신 confidence를 기준으로 삼으세요. 같은 항목에서 AUROC 0.77에 도달합니다. 별개로, noul은 상태 대신 자체 옵션 레이블을 따를 수 있습니다 — 이슈 #156 — 왜냐하면 render_options가 noul의 레이블을 false: / true:로 하드코딩하며, 그 레이블 쌍이 답변을 지배하여 명확히 긍정적인 입력에 대해 확신에 찬 "아니오"를 반환할 수 있기 때문입니다. 문서화된 해결 방법은 같은 질문을 두 가지 옵션의 choice로 중립적인 키를 사용하고 예/아니오 문구를 설명으로 넣어 묻는 것입니다.

넷째, 놓치기 쉽지만 정확히 짚고 넘어갈 만한 캘리브레이션 세부 사항입니다. 체크포인트는 choice:11+ 버킷에 대해 피팅된 온도 0.1006을 함께 제공하며, 로더는 모든 온도를 [0.5, 5.0] 범위로 클램프합니다. 이 클램프는 오히려 도움이 됩니다. 그렇게 날카로운 온도는 실제로는 양분된 분포를 거의 확실한 것으로 보고할 수 있습니다. 클램프 덕분에 최악의 경우에도 피팅이 의도한 것보다 완만한 답변이 나오며, 로더는 영향을 받는 버킷의 이름을 밝히고 해당 신뢰도를 보정되지 않은 것으로 취급하라고 알리는 경고를 출력합니다. 로드할 때 경고를 억제하지 말고 읽어 보세요.

다섯째, 저장소 루트에서는 영어만 사용하며, 영어 이외의 실패 모드는 우아하지 않습니다. 그래서 라우터가 있고, 따라서 사용하라는 권장 사항이 있습니다: 영어 산문이 아닌 모든 것에는 laya-multilingual.

독립적인 그림은, 존재하는 경우에는, 벤더의 그림보다 좁으며 그것과 모순되지 않는다. 독립적인 정면 비교 — sysone-bench, 9개 스위트에 걸친 751개 상태, 2026-09-21 기준, 비교 전에 질문 해시가 동일함을 검증한 바이트 단위로 동일한 입력에서 실행 — 에서는 Jev가 트리아지, 가드레일, 모데레이션, banking77, 다국어 인텐트에서 앞서고, Laya는 AG News(0.940 대 0.910)와 MNLI(0.983 대 0.867)에서 앞선다. 그 신뢰도 게이팅 결과야말로 내가 실제로 계획의 기준으로 삼을 만한 것이다: 0.85 신뢰도에서 게이팅했을 때 Laya 트래픽의 58%를 0.878 정확도로 유지한 반면, Jev는 78%를 0.917로 유지했다. 그것이 이 트레이드오프의 형태다 — Laya는 유지하는 부분에서 더 낮은 정확도로 트래픽을 덜 자동화하며, 자체 라우터 실행은 다국어 인텐트를 0.360에서 0.840으로 끌어올린다.

그것을 둘러싼 표면은 유난히 넓다.

가중치가 겨우 며칠 된 프로젝트라면, 놀라운 부분은 통합 표면이다. 이 모든 것은 업스트림 저장소인 NandhaKishorM/laya에 있으며, 이 글을 작성할 당시 GitHub에서 19,871개의 스타를 기록했고, 전체적으로 Apache 2.0이다:

• laya-serve — Router를 TypeSafe의 호스팅된 Jev API와 동일한 POST /v1/systemone 요청 및 응답 형식으로 노출하는 HTTP 서버이므로, 기존 TypeSafe 클라이언트는 베이스 URL만 변경하면 이전할 수 있습니다. 보안 기본값도 솔직히 밝히자면, 바인딩되는 주소는 인증 없이 0.0.0.0이며, 다만 LAYA_API_KEY가 설정된 경우에는 베어러 토큰을 요구합니다. 강화된 NixOS 모듈 변형도 있는데, 이는 DynamicUser systemd 유닛으로 실행되며 토큰을 LoadCredential을 통해 전달하며 스토어에는 넣지 않습니다.

• 전체 TypeScript 포팅: laya-ts/ (Node 및 브라우저용), 그리고 ONNX 에이전트 경로(laya.onnx_agent.ONNXAgent)를 사용하면 런타임에 PyTorch 없이 내보낸 모델을 ONNX Runtime에서 실행할 수 있습니다.

• 선택적 추가 기능으로 제공되는 MCP 서버로, laya_predict, laya_route, laya_preset 및 laya_status를 도구로 노출합니다.

• LangChain 및 LangGraph 통합 — 신뢰도 임계값과 폴백을 갖춘 조건부 엣지 라우팅을 위한 LayaRouter, 그리고 LayaGuardrail.

• Nix flake에는 nix run .#laya-serve 및 services.laya-serve 모듈, 네 개의 compose 파일, 문서화된 퀵스타트가 포함된 Docker 이미지 경로, 그리고 약 3만 개의 질문을 대상으로 무료 2xT4 GPU에서 4~5시간 안에 전체 RLCD 파인튜닝 루프를 실행하는 Kaggle 노트북이 있습니다.

Apache 2.0은 이것을 제품 안에 넣어 출시할 수 있는지를 결정하는 라이선스 세부 조항입니다. 상업적 사용, 수정, 재배포를 허용하며, 변경 사항이나 파인튜닝한 가중치를 공개하도록 요구하지도 않습니다. 의무는 통상적인 저작자 표시와 고지 보존이며, 여기에 더해 라이선스가 명시한 범위를 넘어서는 특허나 상표권 부여가 명시적으로 없다는 점입니다. 고객 트래픽 앞단에 위치하는 의사결정 계층에게 이는, 가중치와 아키텍처, 학습 레시피가 모두 공개되지 않은 얼리 액세스 호스팅 엔드포인트와는 실질적으로 다른 제안입니다. 그리고 그것이 바로 오늘날의 Jev로, 입력 토큰 백만 개당 0.042달러에 출력은 무료이며 입력 표면은 텍스트 전용입니다.

이것이 실제로 들어가는 자리: 앞에는 의사결정 헤드, 뒤에는 라우팅된 LLM

내면화할 가치가 있는 패턴은 "LLM 대신 결정 모델"이 아니다. 그것은 2단계 파이프라인이며, 두 단계 모두 다른 한 단계가 무언가를 잘하지 못하기 때문에 존재한다.

대량으로 발생하고 범위가 좁으며 기계가 소비할 수 있는 판단 — 티켓 라우팅, 의도 분류, 긴급도 점수화, 이 문서가 쿼리와 관련이 있는지 판단, 이 초안이 정책을 위반하는지 확인 — 에는 Laya를 앞세우세요. 이러한 호출은 정답 집합이 고정되어 있고, 시간당 수천 번 발생하며, 출력 토큰이 0개인 33밀리초 로컬 순전파가 생성형 왕복보다 더 적합합니다. 그런 다음 산문, 종합, 긴 컨텍스트에 대한 추론이 진정으로 필요한 호출 — 초안 작성, 설명, 에스컬레이션 요약 — 에는 생성형 모델을 그 뒤에 배치하세요.

바로 그 지점에 OrcaRouter가 자리하며, 그 경계는 정확히 짚고 넘어갈 가치가 있습니다. 우리는 Laya를 제공하지 않습니다. Laya는 여러분이 직접 실행하는 421M 인코더이고, 그것의 핵심은 데이터가 이미 있는 곳에서 실행된다는 점에 있습니다. Jev도 제공하지 않습니다. Jev는 TypeSafe의 얼리 액세스 엔드포인트입니다. 우리가 담당하는 것은 바로 그 파이프라인의 생성(generative) 절반입니다. 하나의 OpenAI 호환 키 뒤에 200개 이상의 모델이 있고, 제공사 정가를 0% 마크업으로 그대로 전달하며, 제공사 간 자동 페일오버를 지원합니다. 여기서 이것이 중요한 실질적 이유는 두 절반 사이의 이음새입니다. 의사결정 헤드가 거절한 케이스들에 대해 생성 모델로 결정을 라우팅하기 시작하는 순간, 두 번째 통합, 두 번째 청구서, 두 번째 장애 모드가 생깁니다. 생성 측을 위한 키 하나에, 제공사가 성능 저하를 보일 때의 페일오버까지 갖추면, 의사결정 레이어의 에스컬레이션 경로는 두 번째 벤더 관계가 아니라 설정 변경 하나가 됩니다. 작은 주장이지만, 그것이 사실입니다.

누가 도입해야 하고, 누가 기다려야 할까

라벨링된 데이터와 학습 루프가 있고, 특화할 가치가 있을 만큼 안정적인 결정 표면이 있다면 지금 Laya를 도입하세요. Kaggle 노트북이 존재하는 이유는 바로, 파인튜닝 단계가 연구 프로젝트가 되지 않도록 하고, 기본 체크포인트가 CPU에서 약 2초 만에 로드되며, 라이선스 덕분에 가중치를 공개하지 않고도 결과물을 상업적으로 출시할 수 있게 하기 위해서입니다. 가장 잘 맞는 워크로드는 프로젝트가 이미 벤치마킹한 것들입니다: 티켓 트리아지, 인보이스 처리, 보안 인시던트 분류, 가드레일 및 모더레이션, 에이전트 트레이스 관측성. 선택형 질문은 대략 20개 옵션 이하로 유지하고, 프로덕션에 임계값을 적용하기 전에 자체 홀드아웃 데이터로 temperature를 캘리브레이션한 뒤, confidenceact_probability

결정이 레이블된 데이터 없이 별도 설정 없이 바로 정확해야 한다면 기다리세요. 자기가 발표된 벤치마크에서 다수 클래스 기준선을 밑도는 기본 체크포인트는 제로샷 엔진이 아니며, 벤더 대 독립 수치를 솔직하게 해석하면 잘 운영되는 호스팅 결정 API가 현재 더 강력한 제로샷 선택입니다. 또한 옵션 집합이 크고 헤드 예산을 조정할 의향이 없거나, 순서형 점수가 즉시 신뢰할 수 있어야 하거나, 이미지·오디오·장문 문서 입력이 필요하다면 기다리세요 — Laya는 텍스트 전용이고 기본 컨텍스트 예산은 512~1,024토큰이므로, 이는 전체 문서가 아니라 증거를 선별하는 것에 불과합니다.

이 범주를 결정할 것은 지연 시간 수치가 아니다. 그것은 이미 논쟁거리가 되지 않을 만큼 충분히 좋다. 결정할 것은, 당신이 정의한 결정 표면에서 정직한 확률을 보고하고 자신의 레이블로 재훈련할 수 있는 소형 모델이, 대형 생성 모델을 호출해 그 출력을 파싱하는 것보다 더 나은가이다. Laya는 그 질문의 오픈 웨이트 버전에 대한 신뢰할 만한 첫 진지한 시도이며 — 기껏해야 며칠밖에 되지 않았는데, 이는 위의 모든 내용을 읽는 올바른 방식이다. 베이스는 제품이 아니라 출발점이다.