jevlaya
한국어
문서

단계적 도입

Laya는 실행 권한이 아니라 타입이 지정된 의사결정을 돌려줍니다. 증거가 쌓이는 동안 애플리케이션이 실제 동작을 계속 통제하도록, 의사결정 엔진을 단계적으로 도입하십시오.

이 가이드는 Laya를 둘러싼 애플리케이션 측 롤아웃을 설명합니다. Laya는 의사결정, 확률, 신뢰도, 훅 이벤트를 제공하고, 애플리케이션은 기존 동작, 롤아웃 정책, 검토 경계, 롤백을 소유합니다.

1. 섀도: 부작용 없이 관찰

대표성 있는 실제 트래픽에 Laya를 실행하되, 기존 동작이 권위를 유지하게 하십시오. 섀도 기록은 나중에 비교를 재현할 수 있을 만큼 충분한 컨텍스트를 담아야 합니다:

  • 요청 클래스와 Laya 질문 스키마
  • Laya의 답, 선택지별 확률, 신뢰도, 체크포인트, run_id
  • 기존 동작과 최종적으로 검토된 결과 또는 정답
  • 지연 시간, 오류, 그리고 폴백 또는 검토 결정

Laya 측 증거에는 기존 예측 훅을 사용하십시오. 아래 로깅 함수들은 애플리케이션이 소유한 자리 표시자이며, Laya API가 아닙니다:

from laya import Router

class ShadowLog:
    def on_predict_end(self, ctx):
        result = ctx.results[0] if ctx.results else None
        write_shadow_record({
            "run_id": ctx.run_id,
            "model": ctx.model,
            "decision": ctx.decision,
            "result": result,
            "elapsed_ms": ctx.elapsed_ms,
            "error": None if ctx.error is None else repr(ctx.error),
        })

router = Router(hooks=[ShadowLog()])

def handle(request):
    try:
        laya_result = router.predict(request.state, request.questions)
    except Exception as exc:
        record_laya_failure(request, exc)
        return run_incumbent_action(request)
    # The shadow result is recorded by the hook; do not execute it here.
    return run_incumbent_action(request)

민감한 필드는 애플리케이션 정책에 따라 마스킹한 채로 두십시오. 애플리케이션 경계에서 router.predict(...) 주위의 예외를 잡아 기록하십시오. 예측 훅은 예측 생명주기를 커버하지만, 그 생명주기 이전의 실패는 애플리케이션 수준의 포착이 필요합니다. on_predict_end가 그것들을 보았다고 가정하지 마십시오. 섀도 로거는 로깅을 새로운 사용자 대상 동작으로 만들어서는 안 됩니다.

이벤트 순서와 run_id 상관에 대해서는 예측 훅, 훅 생명주기, 트레이싱을 참고하십시오.

2. 비교: 불일치는 신호이지 판결이 아님

같은 요청과 질문 의미에 대해 Laya를 기존 시스템과 비교하십시오. 불일치가 자동으로 오류는 아닙니다. 기존 시스템이 틀렸을 수도, 사례가 모호할 수도, 동작이 사람의 판단을 요구할 수도 있습니다. 가능하면 검토된 레이블이나 정답 결과를 쓰고, 모든 불일치를 이진 점수로 밀어 넣는 대신 명시적인 unknown 또는 검토 버킷을 유지하십시오.

체크포인트, 언어나 라우트, 질문 스키마, 동작 타입, 위험 등급별로 비교를 검토하십시오. 정확도와 나란히 커버리지와 불일치를 기록하십시오. 쉬운 부분집합에서의 높은 일치율은 다른 언어, 동작, 질문 형태로의 승격을 정당화하지 않습니다.

3. 홀드아웃 증거로 정책 선택

신뢰도 임계값은 애플리케이션 정책이지 Laya가 제공하는 속성이 아닙니다. 대표성 있는 홀드아웃 데이터로 의사결정 점수를 적합하거나 캘리브레이션한 뒤, 애플리케이션이 감당할 수 있는 커버리지에서 측정된 정확도와 오류 비용으로 임계값을 고르십시오. 체크포인트, 질문 타입, 언어, 동작 위험을 가로질러 이전되는 보편적인 숫자는 없습니다.

정책과 함께 체크포인트 및 질문 스키마 버전, 캘리브레이션 방법, 임계값, 평가 집합, 담당자를 기록하십시오. 그 입력이 바뀌면 재평가하십시오. 신뢰도는 의사결정을 정렬할 뿐, 의사결정이 옳음을 입증하지 않으며, 높은 신뢰도 자체가 결코 실행 권한이 아닙니다.

그 여섯 중 넷은 평가 하네스에서 나옵니다. laya-evals run --json 보고서는 답한 체크포인트 커밋(config.revisions), 데이터셋의 바이트와 질문 스키마(config.dataset_sha256, config.questions_sha256), 채점된 게이트(config.thresholds)를 기록합니다. 캘리브레이션 방법과 담당자는 애플리케이션이 기록할 몫입니다. 실행 정체성과 기준선과 후보 사이의 비교 가능성 검사는 평가 하네스를 참고하십시오.

README의 자동 신뢰도 게이팅, 캘리브레이션, 정직한 한계 절이 기존의 캘리브레이션과 신뢰도 맥락을 제공합니다. 되돌릴 수 없거나 비용이 큰 동작은 신뢰도가 높더라도 명시적인 검토 경계 뒤에 두십시오.

4. 경계가 있는 슬라이스 승격

승격은 전역 온/오프 스위치가 아니라 측정된, 되돌릴 수 있는 변경이어야 합니다. 자동화를 켜기 전에 적격성 경계를 정의하십시오. 예를 들면:

  • 체크포인트, 언어/라우트, 질문 스키마가 평가된 집합에 있습니다.
  • 동작이 되돌릴 수 있거나 명시적인 사람 검토 경로가 있습니다.
  • 요청이 필수 컨텍스트를 빠뜨리지 않았고 Laya 오류가 없습니다.
  • 슬라이스에 크기나 트래픽 상한과 이름이 붙은 롤백 조건이 있습니다.

작은 카나리로 시작하십시오. 부적격, 모호, 실패 사례에는 검토나 폴백을 유지하십시오. 승격된 의사결정을 계속 샘플링하고, 기존 시스템 및 검토된 결과와 비교하며, 불일치, 커버리지, 폴백 비율, 오류, 지연 시간을 모니터링하십시오. 합의한 가드레일이 깨지면 롤백하십시오. 승격은 경계가 있는 단계이지, 모델이 옳다는 영구적인 선언이 아닙니다.

애플리케이션/Laya 경계

Laya는 의사결정 증거를 제공하고 기존 API와 훅을 통해 노출합니다. 애플리케이션은 기존 결과, 동작 실행, 적격성 규칙, 임계값, 검토, 폴백, 롤백을 소유합니다. 훅은 증거를 기록하거나 주석을 달 수 있지만, 영향이 큰 동작을 실행해도 안전하게 만들어 주지는 않습니다.

따라서 실용적인 롤아웃은 다음과 같습니다:

real request
    ├─ incumbent action (authoritative)
    └─ Laya shadow decision ──> log, compare, evaluate
                                  └─ bounded eligible slice
                                      └─ review / fallback / rollback

롤아웃 체크리스트

  • 섀도 로깅이 부작용이 없고 run_id로 상관됩니다.
  • 비교 데이터가 기존 결과와, 가능한 경우 검토된 레이블 또는 정답 레이블을 포함합니다.
  • 임계값이 대표성 있는 홀드아웃 데이터로 적합되고 검증되었습니다.
  • 되돌릴 수 없거나 비용이 큰 동작에 명시적인 검토 경계가 있습니다.
  • 승격이 경계가 있고, 샘플링되며, 되돌릴 수 있고, 이름이 붙은 폴백과 롤백 경로가 있습니다.
  • 정책 담당자와 재평가 트리거가 기록되었습니다.

함께 보기