벤치마크와 알려진 한계

Laya의 결과는 체크포인트, 작업, 질문 문구, 선택지 개수, 하드웨어에 따라 달라집니다. 체크포인트나 신뢰도 임계값을 고르기 전에 전체 벤치마크 표로 비교 가능한 실행을 찾으십시오. 연구 디렉터리에는 주요 표 뒤에 있는 스크립트와 결과 파일이 있습니다.

관련 측정 찾기

평가하려는 것	시작할 곳	결과를 적용하기 전에 확인할 것
언어 전반의 의사결정	`BENCHMARKS.md`의 MASSIVE와 XNLI 표	언어, 작업, 선택지 개수, 체크포인트
분류나 모더레이션 같은 워크플로	`BENCHMARKS.md`의 애플리케이션 워크플로 표	데이터셋이 학습 구성에 있었는지 홀드아웃이었는지
`laya-typed-decisions` 체크포인트	`BENCHMARKS.md`의 typed-decisions 표	그 벤치마크의 학습 분할로 파인튜닝되었는지, 기반 체크포인트는 별도 행인지
응답 시간	`BENCHMARKS.md`의 T4, GB10, 노트북 CPU, 서버 CPU 절	장치, 배치 크기, 질문 수, 워밍업, HTTP 시간 포함 여부

원래의 Laya 스위트와 나란히 게시된 Jev 수치는 프롬프트와 표본 크기가 다른 제3자 연구에서 나온 것입니다. 유용한 맥락이지만 통제된 직접 대결 실행은 아닙니다. research/README.md의 비교 노트를 참고하십시오.

정확도는 기준선 및 데이터 분할과 함께 읽으십시오. 예를 들어 typed-decisions 벤치마크는 파인튜닝된 체크포인트의 정확도로 0.766을 보고하는데, 두 기반 체크포인트는 그 벤치마크의 다수 클래스 기준선 0.461보다 낮은 점수를 냅니다. 이 결과는 비슷한 작업을 위한 파인튜닝을 뒷받침하지만, 학습되지 않은 체크포인트나 새 도메인에서 0.766의 정확도를 입증하지는 않습니다.

신뢰도는 정확도와 별개로 읽으십시오. 기대 캘리브레이션 오차(ECE)는 보고된 확률이 관측된 정확도와 얼마나 잘 맞는지 측정하며, 낮을수록 좋습니다. 51개 언어 스윕의 원래 ECE와 평균 신뢰도 열은 #42의 온도 클램프 이전 것입니다. 정확도 열은 여전히 적용되지만, 현재 신뢰도 값을 비교할 때는 research/results/의 클램프된 재실행을 쓰십시오. 한 스위트에서 더 낮은 ECE라고 해서 다른 작업이나 선택지 개수에 대한 안전한 임계값이 정해지지는 않습니다.

자기 데이터로 확인할 한계

언어 라우팅: 영어 체크포인트는 영어 밖에서 잘 처리하지 못하는 텍스트에도 신뢰를 보일 수 있습니다. 혼합 언어 입력에는 Router를 쓰고, 서빙하는 언어에서 라우팅 결정을 확인하십시오. 다국어 체크포인트도 영어 MASSIVE와 XNLI 슬라이스에서 영어 체크포인트보다 낮은 점수를 냅니다.
선택지가 많을 때: choice 설명은 고정된 토큰 예산을 공유합니다. 레이블 77개짜리 Banking77 실행은 기본 예산에서 성능이 나쁩니다. 단일 choice 질문은 대략 20개 선택지로 유지하거나, 자기 레이블로 숏리스트와 더 큰 head 예산을 평가하십시오.
캘리브레이션: 두 기반 체크포인트 모두 배포된 상태로 게시된 스위트에서 과신하지만, 별개의 라우팅 작업에서는 과소신했습니다. 신뢰도 게이트를 쓰기 전에 자기 워크플로의 별도 홀드아웃 예제로 온도를 적합하고 평가하십시오.
작업 전이: 애플리케이션 벤치마크에서 홀드아웃 모더레이션은 약하고, 보고된 영어 스위트에서 서수 score가 가장 약한 프리미티브입니다. 다국어 체크포인트는 첫 번째 score 단계에 대한 편향도 측정되었습니다. 실제로 서빙하려는 질문 타입과 데이터 분포를 시험하십시오.
문구와 순서: 선택지 순서가 choice 답을 바꿀 수 있습니다. 불리언 단어를 쓴 choice 레이블과 부정된 요청도 문서화된 예제에서 실패했습니다. noul은 상태가 아니라 자기 선택지 레이블을 따를 수 있습니다. 특히 잘못된 의사결정의 비용이 클 때는 다른 선택지 순서와 문구를 확인하십시오.
긴 문서: 다국어 인코더는 그 한도로 설정하면 최대 8,192토큰까지 읽을 수 있지만, 장문 컨텍스트 벤치마크는 앞선 텍스트가 약 4,000토큰을 넘으면 답이 덜 신뢰할 만하다고 보고합니다. 실제 사용에서 예상되는 길이에서 정확도를 측정하십시오.
지연 시간: T4 수치는 CPU나 콜드 로드 시간을 예측하지 못합니다. 자기 체크포인트, 장치, 입력 길이, 질문 수로 워밍 상태와 콜드 상태의 호출을 측정하십시오.

README의 정직한 한계 절에 예제와 현재의 우회 방법이 있습니다. 벤치마크 표는 위의 각 한계 뒤에 있는 데이터셋과 하드웨어를 제시합니다.

결과 재현 또는 확장

스크립트와 결과 지도와 BENCHMARKS.md 맨 위의 실행 인덱스에서 시작하십시오. research/scripts/bench_local.py는 51개 언어 CPU 스윕을 실행하고, bench_apps.py는 애플리케이션 워크플로를 다루며, bench_latency.py는 라우팅과 추론 속도를 측정합니다. T4 노트북은 research/scripts/build_benchmark_nb.py에서 생성되므로, 그 벤치마크를 바꿀 때는 생성기를 편집하십시오.

새 배포에서는 비교하는 모든 체크포인트에 대해 같은 상태, 질문, 기대 답을 가진 홀드아웃 집합을 유지하십시오. 각 실행에 체크포인트 리비전, Laya와 라이브러리 버전, 장치, 질문 수, 선택지 개수, 토큰 예산을 기록하십시오. 정확도를 위한 단순 기준선을 포함하고, 첫 사용 로드 시간뿐 아니라 워밍업 후 지연 시간도 보고하십시오. 그래야 결과를 게시된 실행과 비교할 수 있고 업그레이드 후 다시 살펴볼 수 있습니다.