자신의 의사결정으로 Laya 파인튜닝하기

typed-decisions 벤치마크에서 기반 체크포인트는 제로샷으로 거의 무작위에 가까운 점수를 냅니다 —— 0.318 무작위 기준선에 대해 0.36과 0.35 —— 반면 파인튜닝된 체크포인트는 같은 2,000개 의사결정에서 0.766에 도달하며, TypeSafe Jev의 공개된 0.727보다도, 0.735인 교사 자기 일치 상한보다도 높습니다. 파인튜닝이 가치의 대부분을 차지하며, 공개 파인튜닝 노트북이 Kaggle의 무료 2xT4 GPU에서 전체 루프를 실행합니다. 데이터셋을 만들고, RLCD로 학습하고, 캘리브레이션 온도를 적합하고, 평가하고, 결과를 Hub로 푸시합니다. 이 페이지는 그 노트북을 짚어 가며, 데이터를 자신의 것으로 바꿀 때도 여전히 중요한 부분을 가리킵니다.

다른 실습 예제 —— 유료 API 없이 단일 16 GB GPU에서의 브라우저 에이전트 의사결정 head —— 는 Laya를 브라우저 에이전트 의사결정 head로 파인튜닝하기에 있습니다.

노트북이 하는 일, 순서대로

Kaggle 설정: Accelerator GPU T4 x2, Internet On. 출력은 /kaggle/working/laya_finetuned_typed_decisions에 남습니다.

학습 레시피

RLCD는 하드 레이블이 아니라 벤치마크의 골드 분포로 학습합니다. 모든 항목이 교사가 각 선택지에 할당한 확률을 지니고, 손실의 두 절반 모두 그 타깃을 읽습니다 —

• 샘플링된 노이즈 있는 로짓 투영에 대한 정책 그래디언트 항(GRPO 스타일: 항목당 네 샘플, 탐험 노이즈 0.4 → 0.1로 어닐링), 적절한 스코어링 규칙(구면 0.75, 순위 확률 1.0)으로 보상됨
• 같은 분포에 대한 전가중치 소프트 교차 엔트로피 항

노트북이 16 GB 카드를 위해 설정하는 손잡이:

2xT4에서 런타임은 데모에 몇 분, 실제 데이터에 몇 시간입니다. 데모의 6,000개 의사결정에 약 46분, 약 30k 질문에 대한 네 에포크에 대략 45시간입니다.

자신의 데이터로 향하게 하려면 두 개의 load_dataset 호출을 바꾸고 행 스키마를 유지하십시오. 각 사례는 state, questions, gold(질문별 교사 확률)를 지니고, 전처리기가 그것들을 항목으로 바꿉니다. 질문 타입은 choice, score, noul이며, 그것들로 상태에 대해 표현할 수 있는 것은 무엇이든 대상이 됩니다.

캘리브레이션은 실행의 일부

이것은 루프를 복사할 때 가장 빠뜨리기 쉬운 단계이며, 누군가 신뢰도로 게이팅하는 순간부터 중요한 부분이 됩니다.

노트북은 랭크에 샤딩하기 전에 학습 데이터에서 캘리브레이션 슬라이스를 떼어 냅니다(최대 400개 항목 또는 10%, 고정 시드, 모든 랭크에서 동일). 실행이 이미 학습한 항목에 온도를 적합하면 캘리브레이션이 아니라 적합도를 측정하게 됩니다. 모델이 그것들에 거의 확신하고 거의 정확하므로, 옵티마이저가 부드럽게 할 것이 없어 퇴화한 스케일을 돌려줍니다.

마지막 에포크 후 랭크 0이 질문 타입별 온도 하나씩(choice, score, noul)을 로그 온도에 대한 LBFGS로 적합하며, [0.1, 10]으로 클램프합니다(항목이 열 개 미만인 슬라이스에는 1.0, 적합이 예외를 내면 1.2). 값은 temperature로 rl_agent_config.json에 들어가고, 노트북은 같은 쓰기에서 상속된 temperature_by_options를 제거합니다. 그 오래된 버킷 값이 추론 시 우선하며 새 적합을 조용히 가릴 것이기 때문입니다.

온도 스케일링은 argmax와 정확도를 바꾸지 않으며, 움직이는 것은 신뢰도입니다. 배포되는 체크포인트는 과신하므로, 어떤 임계값에든 의존하기 전에 적합하고, 개선을 주장하기 전에 홀드아웃 데이터로 결과를 평가하십시오. 구성 지속성 회귀는 다운로드나 학습 없이 실행됩니다:

python tests/test_calibration_persistence.py

신뢰하기 전에 평가

평가는 공식 테스트 분할에 대한 전체 패스입니다. Agent Trace Observability, Customer Service, Invoice Processing, Security Incidents에 걸친 400개 사례, 2,000개 의사결정입니다. 정확도, 소프트 정확도, Brier, ECE(laya.common.ece_score 경유), score MAE, 1단계 이내, 지연 시간 백분위를 계산한 뒤, 참조 행이 고정된 직접 대결 표를 만듭니다:

자신의 실행에서 Laya 행도 같은 방식으로 계산됩니다. 노트북이 실행 자체의 수치로 표를 다시 만듭니다. 따라 할 만한 두 가지 습관: 관심 있는 슬라이스(언어, 워크플로)를 홀드아웃 데이터 안에 두고, 정확도 옆에 캘리브레이션을 보고하십시오. 학습 신호가 레이블만이 아니라 분포이기 때문입니다. 수치가 나오면 저장소의 Discussions에 글을 올려 공유하십시오. 벤치마크와 알려진 한계는 저장소 루트의 BENCHMARKS.md에 있습니다.

Hub로 푸시

게시 셀은 루프의 마지막 구간이며, 의도적으로 따분합니다:

1. Kaggle에 쓰기 HF_TOKEN을 넣으십시오(Add-ons → Secrets). 없으면 셀이 정확한 안내와 함께 예외를 발생시킵니다.
2. 목적지 저장소를 설정하십시오 —— 배포된 셀은 프로젝트 자체 네임스페이스의 이름을 기본값으로 하므로, 실행 전에 바꾸십시오.
3. 실행하십시오. 이 실행의 비교 표에서 나온 수치로 모델 카드를 쓴 뒤, model.safetensors, encoder/, tokenizer/, rl_agent_config.json, 카드, 벤치마크 보고서를 업로드합니다.

결과는 다른 체크포인트와 똑같이 로드됩니다 —— 파인튜닝 전용 API는 없습니다:

import laya

agent = laya.load("your-org/your-checkpoint")   # the repo you just pushed
result = agent.predict(state, questions)

롤링 checkpoint_latest/는 에포크마다 덮어써지므로, Kaggle 타임아웃이나 OOM은 실행 전체가 아니라 에포크 하나를 잃게 합니다.

주의할 점

• 루프는 타깃만큼만 좋습니다. RLCD는 당신의 질문에 대한 교사 분포를 모방합니다. 학습 전(또는 학습과 함께) 교사 신뢰도를 수집하고, 그 품질을 상한으로 취급하십시오.
• 캘리브레이션 슬라이스는 의도적으로 작습니다. 최대 400개 항목 또는 10% —— 타입별 스칼라 세 개에는 충분하지만, 검증에 쓰기에는 부족합니다. 자신의 평가 데이터를 따로 떼어 두십시오.
• 당신의 레이블은 세 프리미티브에 맞아야 합니다. 의사결정이 choice, 척도, 예/아니오 확률이 아니라면, 먼저 그중 하나로 형태를 갖추십시오. 두 날카로운 모서리는 이미 문서화되어 있습니다. 선택지가 많으면 신뢰도 선택이 나빠지고(#394), 강제 선택 부정은 상태보다 질문을 따를 수 있습니다(#377).
• 가중치만이 아니라 구성을 배포하십시오. 제거된 temperature_by_options는 복사된 구성에 살아남으면 캘리브레이션을 조용히 풀어 버리는 부분입니다.