평가(Evals)

docs.scrimba.com

프롬프트를 변경하고, 한 번 시도해보고, 답변이 더 좋아 보여서 배포했는데, 일주일 후에 사용자가 이전보다 더 나빠진 경우를 마주치게 됩니다. 평가(eval) (evaluation의 약자)는 해결책입니다. AI 기능이 작동하는지를 반복적으로 테스트하는 것으로, 입력값과 그에 대한 좋은 출력값이 무엇인지 짝지어진 세트이고, 매번 같은 방식으로 채점되어 변경사항이 실제로 도움이 되었는지 알 수 있습니다. 모델은 확률론적 블랙박스로 같은 질문에 매번 다르게 답변하므로, 측정이 알 수 있는 유일한 방법이며, 이러한 규율이 데모와 제품을 구분하는 많은 부분입니다.

육안 검사가 실패하는 이유

AI의 답변을 손으로 확인하는 것은 처음에는 괜찮아 보입니다. 프롬프트를 실행하고, 답변을 읽고, 괜찮아 보이므로 계속 진행합니다. 문제는 세 가지가 조용히 당신을 방해하고, 당신이 이미 모두 겪었다는 것입니다.

세 가지는 다음과 같습니다:

• 출력이 변합니다. 같은 프롬프트는 실행마다 다른 답변을 줄 수 있으므로, 한 번의 좋은 결과가 다음 결과도 좋을 것이라고 보장하지 않습니다.
• 변경사항이 회귀를 유발합니다. 한 경우를 고치는 프롬프트 편집은 종종 보고 있지 않은 다른 경우를 깹니다.
• 확장되지 않습니다. 다섯 개의 답변은 읽을 수 있습니다. 한 줄을 변경할 때마다 오백 개를 읽을 수는 없습니다.

이 중 어느 것도 당신이 뭔가 잘못했다는 의미가 아닙니다. 이는 육안 검사가 이 크기의 작업에 적합한 도구가 아니라는 의미이고, 더 평화로운 방법이 있다는 것입니다.

Juno육안 검사가 실패하는 이유 손으로 답변을 읽는 것은 세 가지 이유로 분해됩니다. 모두 모델이 어떻게 작동하는지에 뿌리를 두고 있습니다: 출력이 실행마다 변하고, 편집은 보고 있지 않은 경우를 조용히 깨고, 수백 개의 답변이 있으면 손으로 따라갈 수 없습니다. 이는 규율 문제가 아니라 작업의 크기에 맞지 않는 도구입니다. 좋은 소식은 해결책이 친절하고 곧 올 것입니다.

한 개의 답변을 읽는 것은 거의 아무것도 알려주지 않으며, 그 이유는 모델이 어떻게 작동하는지에 있습니다. 출력이 비결정론적이기 때문에 (같은 프롬프트는 실행마다 다른 답변을 줄 수 있음), 한 개의 답변은 크기 1의 표본입니다. 같은 경우에 대해 많은 실행이 필요하기 때문에 실제로 얼마나 자주 작동하는지 추정하기 위해 통과율(pass rate), 올바르게 나오는 경우의 비율을 알려줄 수 없습니다.

회귀도 관련된 이유로 숨어 있습니다. 한 경우를 손으로 고치면 다른 경우에 대한 기록이 없으므로, 다음 편집은 보고 있던 것을 깰 수 있습니다. 이를 보는 유일한 방법은 매번 같은 방식으로 채점되는 고정된 경우의 세트이므로, 감소가 놀라움 대신 숫자로 나타납니다.

이 수학 위에 인간 문제가 있습니다. 수동 검토는 사람 사이와 기분 사이에서 표류합니다: 같은 답변은 월요일에는 괜찮아 보이고 금요일에는 약해 보입니다. 따라서 이동은 "괜찮아 보인다"를 고정된 경우의 세트에 대한 측정된 통과율로 변환하는 것입니다. 느낌을 같은 경우에 대한 숫자로 바꾸세요.

Juno육안 검사가 실패하는 이유 한 개의 답변은 크기 1의 표본이므로, 모델이 한 번 작동했다는 것만 알려주고 얼마나 자주 작동하는지는 알려주지 않습니다. 실제 통과율을 보려면 많은 경우를 실행하고; 회귀를 잡으려면 그 경우의 세트를 고정하고 매번 같은 방식으로 채점합니다. 수동 검토도 검토자와 함께 표류하므로, 작업은 "괜찮아 보인다"를 측정된 숫자로 대체하는 것입니다.

정확한 확인은 당신이 부주의해서 실패하지 않습니다. 이는 선택 편향이 내장되어 있기 때문에 실패합니다: 당신은 작동할 것이라고 예상하는 경우를 보므로, 확인하지 않는 동작이 사용자 앞에서 회귀하는 것입니다. 추적하지 않는 메트릭은 정확히 이동하는 것입니다.

기준 점수가 없으면, 모든 품질 변경은 당신이 스스로에게 하는 이야기입니다. 이동을 특정 편집에 귀속시킬 수 없고, 변경 세트를 이등분하여 어떤 것이 통과율 (올바르게 나오는 경우의 비율)을 떨어뜨렸는지 찾을 수 없습니다. 왜냐하면 이전을 측정한 적이 없기 때문입니다. "더 나은 것 같다"는 모순이 없기 때문에 살아남습니다.

느낌 기반 반복도 과적합됩니다. 같은 소수의 예시를 계속 다시 입력하고, 그것들이 올바르게 보일 때까지 조정하고, 조용히 그 작은 개인 세트에 프롬프트를 훈련시키는 동안 실제 트래픽은 다른 곳으로 표류합니다. 수동 검토는 새로운 입력이 입력하지 않는 것이기 때문에 그 분포 이동을 볼 수 없습니다. 버전이 지정된 평가 세트와 추적된 점수만이 변경사항이 도움이 되었다고 느껴지기보다 말할 수 있는 방법이고, 이것이 반복과 추측의 차이입니다.

Juno육안 검사가 실패하는 이유 나는 느낌으로 배포했다가 정확히 확인하지 않은 한 경로가 오류 로그를 밝히는 것을 본 적이 있습니다. 선택 편향이 제 역할을 합니다. 기준이 없으면 귀속도 없고 이등분도 없습니다: 숫자가 없으면 어떤 편집이 숫자를 움직였는지 증명할 수 없습니다. 버전이 지정된 세트와 추적된 점수를 유지하거나, 계속 다시 입력하는 다섯 개의 예시에 과적합하는 동안 실제 트래픽은 볼 수 없는 곳으로 걸어갑니다.

평가 세트 구축

평가 세트는 테스트 경우의 목록입니다. 각 경우에는 입력값과 그에 대한 좋은 출력값이 무엇인지가 있습니다. 작게 시작하세요. 일반적인 상황과 몇 가지 까다로운 경계 사례를 다루는 10개에서 20개의 경우가 없는 것보다 훨씬 더 유용하며, 야생에서 새로운 실패를 발견하면서 세트를 확대할 수 있습니다.

eval_set = [
    {"input": "음식이 차갑고 늦었다.", "expected": "NEGATIVE"},
    {"input": "내 인생 최고의 식사!", "expected": "POSITIVE"},
    {"input": "그냥 괜찮았고, 특별한 건 없었다.", "expected": "NEUTRAL"},
    # ...발견하면서 실제 경우와 경계 사례를 추가하세요
]

사용자가 나쁜 답변을 보고할 때, 주어졌어야 했던 출력과 함께 세트에 추가합니다. 그러면 평가 세트는 다시 실패하고 싶지 않은 모든 실수에 대한 증가하는 기억이 되고, 고친 버그가 계속 유지하는 테스트가 되는 것처럼 말입니다.

Juno평가 세트 구축 평가 세트는 테스트 경우의 목록입니다: 입력값과 좋은 답변이 무엇인지. 일상적인 상황과 몇 가지 까다로운 것을 다루는 10개에서 20개로 시작하세요. 사용자가 나쁜 답변을 마주칠 때마다 주어졌어야 했던 답변과 함께 추가하면, 세트가 조용히 반복하고 싶지 않은 모든 실수를 기억합니다.

**평가 세트**는 테스트 경우의 모음이며, 각 경우는 입력값과 좋은 것으로 받아들일 출력값으로 쌍을 이룹니다. 중요한 숫자는 크기가 아니라 커버리지입니다. 20개의 잘 선택된 경우가 50개의 일회용 경우를 항상 이깁니다.

세 가지를 커버하는 것을 목표로 하세요: 사용자가 실제로 마주치는 일반적인 경로, 두 레이블이 가까이 앉아 있는 결정 경계 (줄 위의 모호한 경우), 그리고 이미 문제가 된 알려진 실패 모드. 손으로 고른 친절한 입력은 점수를 좋게 보이게 하고 아무것도 알려주지 않으므로, 세트를 실제 트래픽을 대표하도록 유지하세요.

사용자가 보고하는 모든 버그는 세트의 영구적인 경우가 됩니다. 이는 이를 회귀 스위트로 전환합니다: 고쳐진 버그는 고쳐져 유지됩니다. 왜냐하면 이를 노출시킨 경우가 이제 매번 실행되기 때문입니다. 기대 출력이 자유 텍스트가 아닌 구조화된 경우 (레이블이나 JSON 필드), 정확한 일치 비교로 채점할 수 있으며, 이는 깔끔하고 모호하지 않습니다. 구조화된 출력을 참조하세요.

당신이 조정하지 않는 별도의 유지 세트를 유지하세요. 당신이 보고 있는 정확한 경우를 통과할 때까지 프롬프트를 조정하면, 당신이 이미 공부한 답변에 자신에게 등급을 매기고 있으며, 점수는 더 이상 아무것도 의미하지 않습니다.

Juno평가 세트 구축 원시 크기보다 커버리지: 일반적인 경로, 레이블 사이의 모호한 경계, 그리고 이미 본 실패를 칩니다. 보고된 모든 버그를 영구적인 경우로 전환하여 세트가 회귀 스위트처럼 작동하도록 합니다. 조정하지 않는 유지 세트를 유지하거나, 당신이 공부한 답변에 자신에게 등급을 매기고 있습니다.

**평가 세트**를 프롬프트 바로 옆에 버전이 지정된 자산으로 취급하세요. 왜냐하면 둘은 함께 이동하고 프롬프트 변경은 좋은 답변이 무엇인지를 조용히 이동시킬 수 있기 때문입니다. 세트의 레이블 품질은 메트릭의 천장입니다: 하나의 잘못된 "expected" 값이 점수를 제한하고 조용히 잘못된 교훈을 가르치므로, 경우를 수집하는 것만큼 레이블을 신중하게 큐레이션하는 것이 중요합니다.

테스트 누출을 방지하세요. 보고하는 정확한 세트를 통과할 때까지 조정하면, 숫자는 극장입니다. 반복할 때 보지 않는 슬라이스를 유지하고, 어쨌든 조정 루프에 천천히 누출되지 않도록 시간이 지남에 따라 회전합니다.

클래스 균형을 보세요. 90%가 명확한 긍정인 세트는 우아한 숫자를 보고하면서 실제로 중요한 10%의 모든 실패를 숨길 것이므로, 어렵고 드문 경우가 실제 무게를 갖도록 샘플링하세요. 상상에서가 아닌 프로덕션 로그에서 경우를 풀어내세요. 실제 트래픽은 당신이 책상에서 결코 발명할 수 없는 표현을 표면화하기 때문입니다.

세트가 부패한다는 것을 받아들이세요. 제품이 이동하면서 오래된 경우는 사용자가 보내는 것을 반영하지 못하게 되고 새로운 실패 모드가 나타나서 세트가 본 적이 없습니다. 큐레이션하는 것은 일회성 구축이 아닌 지속적인 작업입니다.

Juno평가 세트 구축 세트는 프롬프트 옆에 버전이 지정된 자산이고, 레이블 품질은 메트릭의 어려운 천장이며, 하나의 나쁜 expected 값이 전체 점수를 제한합니다. 슬라이스를 유지하고 회전하거나, 보고된 숫자는 극장입니다. 클래스 균형을 보고, 로그에서 실제 경우를 샘플링하고, 제품이 이동하면서 세트가 부패한다고 가정하므로, 큐레이션은 정말로 끝나지 않습니다.

채점 방법

다른 작업은 다른 채점이 필요하므로, 첫 번째 단계는 확인을 기대하는 답변의 종류와 일치시키는 것입니다.

• 정확한 일치는 한 가지 올바른 답변이 있을 때 작동합니다: 분류 레이블, 추출된 필드, 예 또는 아니오. 출력을 기대값과 직접 비교합니다.
• 기준 기반 채점은 요약이나 답변처럼 올바른 단일 답변이 없을 때 작동합니다. 출력이 조건을 충족하는지 확인합니다: 요약이 핵심 사실을 언급하나요? 50단어 이하인가요? 톤이 정중한가요?
• 판사로서의 LLM은 기준에 대한 출력을 채점하기 위해 두 번째 모델 호출을 사용합니다. 간단한 확인이 포착할 수 없는 모호한 품질 질문으로 확장되지만, 판사는 자신이 모델이므로 틀릴 수 있고, 때때로 인간 판단에 대해 정신 수표를 합니다.

# 평가 세트에 대한 정확한 일치 채점
def run_evals(eval_set, classify):
    passed = 0
    for test in eval_set:
        output = classify(test["input"])
        if output == test["expected"]:
            passed += 1
        else:
            print(f'FAIL: "{test["input"]}" -> got {output}, wanted {test["expected"]}')
    print(f"{passed}/{len(eval_set)} passed")

정확한 일치는 시작하기에 가장 친절한 곳이고, 이전 장의 분류 및 추출 작업과 완벽하게 맞습니다. LLM-as-judge 아이디어는 답변이 표준을 충족하는지 확인하는 것이 종종 답변을 생성하는 것보다 더 쉬운 예측이기 때문에 작동합니다. 에세이를 검토하는 것이 쓰는 것보다 쉬운 것과 같은 방식입니다. 하지만 판사는 같은 결함을 가진 또 다른 예측기이므로, 점수를 유용한 추정치로 취급하고, 명확한 루브릭을 주고, 때때로 표본에 대한 자신의 점수에 대해 확인하세요.

Juno채점 방법 답변에 맞는 확인을 선택하세요: 하나의 올바른 답변이 있을 때 정확한 일치, 여러 좋은 것이 있을 때 기준, 모호한 품질에 대해 두 번째 모델을 판사로 합니다. 정확한 일치는 친절한 시작이고, 이미 연습한 분류 및 추출과 깔끔하게 정렬됩니다. 하지만 판사도 모델이므로, 때때로 자신의 점수를 직접 확인해 보세요.

작업에 **채점자(grader)**를 일치시킨 다음, 신경 쓰는 것을 여전히 포착하는 가장 싼 것에 도달하세요. 그래더는 출력이 통과했는지를 결정하는 코드 또는 모델 호출이고, 잘못된 선택은 실제 실패를 놓치거나 괜찮던 답변을 플래그합니다.

정확한 일치는 레이블 및 추출된 필드용입니다: 출력을 기대값과 비교하고 결과는 결정론적이므로, 신뢰할 수 있습니다. 구조화된 출력과 자연스럽게 쌍을 이룹니다. 모델이 고정된 스키마를 반환하므로 자유형식 산문 대신 비교할 깔끔한 것을 제공합니다.

프로그래매틱 기준은 중간 지점을 싸게 덮습니다: 길이를 확인하고, 필수 문자열이 있는지 확인하고, JSON이 구문 분석되는지 유효성을 검사하고, 정규식을 실행합니다. 이들은 모델 호출 없이 밀리초 단위로 실행되므로, 판사에 돈을 쓰기 전에 반정형 구조 무엇이든 사용하세요.

LLM-as-judge는 요약이나 답변이 많은 좋은 형태를 가지고 있고 정확한 목표가 없는 개방형 품질용입니다. 판사가 일관된 표준을 적용하도록 작성된 루브릭이 필요하고, 표본에 대한 점수를 레이블과 비교하는 보정 확인이 필요합니다. 그래더도 코드이므로 신뢰해야 한다는 것을 기억하세요: 불안정한 그래더는 자신감 있는 잘못된 점수를 줍니다.

Juno채점 방법 가장 싼 그래더를 사용하세요. 레이블 및 필드에는 정확한 일치, 길이나 유효한 JSON이나 필수 문자열을 확인하려면 프로그래밍 방식 확인, 개방형 품질에만 모델 판사를 사용합니다. 정확한 일치는 구조화된 출력과 잘 쌍을 이루므로 고정 스키마가 비교할 깔끔한 것을 제공합니다. 선택한 것이 무엇이든, 그래더는 또한 신뢰하는 코드이므로, 불안정한 것은 자신감 있는 잘못된 점수를 줍니다.

LLM-as-judge는 가장 흥미로운 방식으로 부서지는 그래더이므로, 이에 기대기 전에 편향을 계획하세요. **판사**는 더 긴 답변을 선호하고, 쌍을 비교할 때 첫 번째 옵션을 선택하고, 자신의 스타일처럼 읽는 텍스트에 보상하고, 절대 점수는 형편없이 보정되어 있으므로, 한 실행의 8은 다음 실행의 8이 아닙니다.

판사를 자신의 권리로 평가하는 모델로 취급하세요. 판사 모델을 핀으로 고정하고 버전을 지정하세요. 업데이트될 때 표류하고 점수가 함께 이동하기 때문입니다. 몇 가지 앵커 예제와 함께 타이트한 루브릭을 제공한 다음, 레이블이 지정된 표본에서 판사-대-인간 동의를 측정하므로 얼마나 멀리 신뢰할지 알 수 있습니다.

할 수 있는 경우, 절대 1~10 점수 대신 쌍 방향 비교를 요청하세요 ("A 또는 B가 더 낫나요?"); 상대 판단은 모델이 보정된 숫자를 치도록 요청하는 것보다 보통 더 신뢰할 수 있습니다. 판사를 핀으로 고정하고, 루브릭을 타이트하게, 인간에 대해 확인하세요.

순환성과 청구서를 주의하세요. 같은 모델 패밀리가 자신의 출력에 등급을 매기면 같은 맹점을 공유하므로, 생성기가 만든 결함은 판사가 놓칠 가능성이 높은 결함이고, 모든 경우를 규모로 판단하는 것은 첫 번째 위에 두 번째 모델 청구서입니다.

Juno채점 방법 판사는 요청하지 않은 의견을 가집니다: 긴 답변, 첫 번째 옵션, 자신처럼 읽는 산문을 좋아하고, 절대 점수는 실행 사이에서 표류합니다. 핀으로 고정하고 버전을 지정하고, 앵커가 있는 타이트한 루브릭을 전달하고, 인간과 얼마나 자주 동의하는지 추적하세요. 왜냐하면 당신은 이제 그래더를 등급을 매기고 있기 때문입니다. 외로운 1~10 위의 쌍 비교를 사용하세요, 그리고 모델이 자신의 패밀리를 판단하면 같은 맹점을 공유하고 청구서를 두 배로 한다는 것을 인식하세요.

모든 변경사항에 대해 실행

평가 세트는 실제로 실행할 때만 유용합니다. 프롬프트를 코드처럼 취급합니다: 프롬프트, 모델 또는 검색의 변경사항을 배포하기 전에, 평가를 실행하고 점수를 이전과 비교합니다. 숫자가 내려갔다면, 당신의 한 손 테스트가 괜찮아 보였더라도, 회귀를 유발했습니다.

이것이 프롬프트 엔지니어링을 추측에서 자신감을 가지고 반복할 수 있는 것으로 바꿉니다. 뭔가를 변경하고, 측정하고, 더 높은 점수를 기록하고, 더 낮은 점수를 기록합니다. 이는 일반 소프트웨어를 신뢰할 수 있게 하는 같은 루프이고, 이제 AI 기능의 모호한 부분에 적용됩니다.

점수가 떨어졌다면, 회귀를 유발했습니다. 한 번의 운 좋은 손 테스트는 세트를 무시하지 않으므로, 매번 숫자를 동점 부수로 놔두세요.

Juno모든 변경사항에 대해 실행 평가 세트는 실행할 때만 도움이 되므로, 습관을 만드세요: 변경사항을 배포하기 전에 평가를 실행하고 마지막 점수에 대해 확인합니다. 떨어졌다면, 피할 불운이 아닌 회귀입니다. 변경하고, 측정하고, 더 높은 점수를 기록하면, 당신은 반복하고 있습니다.

평가 실행을 개발 루프에 연결하여 테스트 스위트가 병합을 기록하는 방식으로 변경을 기록하세요. 프롬프트, 모델 또는 검색 (지원 문서를 가져오는 단계)에 대한 변경사항은 세트를 실행하고 점수를 이전 실행과 비교할 때까지 배포되지 않습니다. 숫자, 손 테스트 후의 장난감이 아닌, 변경사항이 개선인지 여부를 결정합니다.

한 번에 하나의 변수를 변경합니다. 프롬프트를 편집하고 같은 패스에서 모델을 교체하면, 점수의 이동은 두 가지 가능한 원인을 가지고 있고 어느 쪽에도 귀속시킬 수 없습니다. 변경을 격리하고, 세트를 실행하고, 결과를 읽고, 다음으로 이동합니다.

합계 점수 (모든 경우에 걸쳐 평균화된 단일 숫자)뿐만 아니라 경우별 차이를 읽으세요. 안정적인 합계는 하나의 경우가 고쳐지고 하나가 같은 시간에 깨져 0으로 순환하는 동안 동작이 조용히 이동한다는 것을 숨길 수 있습니다. 어떤 경우가 뒤집혔는지 보면 당신의 변경사항이 실제로 수행한 것을 알려줍니다.

시간이 지남에 따라 점수를 추적하므로 개선이 보이고 회귀가 눈에 띕니다. 로그된 기록은 "이것이 더 나은 것 같다"를 가리킬 수 있는 선으로 바꾸고, 급격한 하락을 빠르게 추적하여 유발한 변경으로 돌아갑니다.

Juno모든 변경사항에 대해 실행 테스트가 병합을 기록하는 방식으로 점수에 변경을 기록합니다: 실행 없음, 배포 없음. 패스당 하나의 변수를 변경하여 점수 이동이 하나의 원인을 가지고 있고, 경우별 차이를 읽으므로, 플랫 합계는 하나의 경우가 고쳐지고 하나가 깨졌습니다. 시간이 지남에 따라 점수를 기록하여 승리가 보이고 회귀가 눈에 띕니다.

의식 의식이 아닌 실제 게이트를 만드세요. 점수가 설정한 막대 아래로 떨어지면 변경사항이 실패하도록 CI에 점수 임계값을 넣어서 누군가가 보는 것을 기억하는 것에 의존하는 대신입니다. 그리고 같은 프롬프트가 새로운 무게에 다르게 착지하기 때문에 모든 모델 버전 범프에서 세트를 다시 실행합니다; 모델 버전을 핀으로 고정하고 새 버전을 채택하기 전에 다시 평가합니다.

두 함정을 마음에 유지합니다. 첫째, 평가 세트 (기대 결과가 있는 테스트 경우의 고정 모음)는 프록시이지 기본 진실이 아니므로, 이에 대해 열심히 조정하면 과적합합니다: 실제 동작이 정체되는 동안 점수를 올립니다. 세트를 계속 확대하고 회전하므로 시험하는 것이 아닌 작업을 측정합니다.

둘째, 오프라인 평가가 전체 그림이 아닙니다. 온라인 신호, 샘플 프로덕션 트래픽, 사용자 피드백, 불만 비율과 쌍으로 묶고, 실제 실패를 새로운 경우로 세트에 다시 피드합니다.

출력이 비결정론적이기 때문에, 같은 입력은 실행 간에 다르게 채점할 수 있습니다. 경우당 충분한 표본을 실행하고, 단일 실행 노이즈를 쫓는 대신 관용에 대해 판단합니다; 실행 사이의 1점 변동은 측정 호흡이고, 회귀가 아닙니다. 그 분산을 살아남는 수준으로 막대를 설정하거나, 유령을 조사하며 주를 보낼 것입니다. 나는 정확히 그렇게 한 적이 있습니다. 한 번 이상.

Juno모든 변경사항에 대해 실행 점수가 나쁜 변경사항이 실패하도록 CI에 임계값을 넣고, 새로운 무게가 같은 프롬프트를 다르게 읽기 때문에 모든 모델 버전 범프에서 다시 평가합니다. 세트는 프록시이므로, 이를 계속 회전하고 온라인 신호와 쌍으로 묶으거나, 자신의 시험에 과적합합니다. 그리고 출력이 비결정론적이므로, 유령을 조사하는 대신 관용에 대해 판단하세요. 네, 나는 했습니다.

실전에서

마지막 섹션의 run_evals 함수는 완전하고, 작으면, 평가 조랑마입니다. 이를 분류기와 평가 세트로 가리키면, 통과하는 경우와 정확히 실패하는 경우를 알려줍니다:

run_evals(eval_set, classify_review)
# FAIL: "그냥 괜찮았고, 특별한 건 없었다." -> got POSITIVE, wanted NEUTRAL
# 2/3 passed

그 하나의 실패 선은 수십 개의 성공한 손 테스트보다 가치가 있습니다. 왜냐하면 고칠 수 있는 실제 약점을 가리키고 다시 측정하기 때문입니다. 마지막 장, 안전 및 제한, 실제 사용자 앞에 놓기 전에 설계할 위험을 다룹니다.

Juno실전에서run_evals과 같은 작은 조랑마가 이미 비용을 지불합니다: 점수와 정확히 깨진 경우 목록을 제공합니다. 하나를 고치고, 다시 실행하고, 숫자가 이동하는 것을 보세요. 다음으로, 안전 및 제한은 실제 사용자가 도착하기 전에 보호해야 할 것을 다룹니다.

작은 평가 조랑마, 평가 세트의 모든 경우를 실행하고 출력을 기대값에 대해 채점하는 코드 조각, "괜찮아 보인다"를 이동할 수 있는 숫자로 바꾸는 루프입니다. 세트를 실행하고, 점수와 실패 목록을 얻고, 가장 싼 실제 실패를 고치고, 다시 실행합니다.

각 실패 경우는 명확한 완료 정의가 있는 작업 단위입니다: 경우가 통과합니다. 이것이 "프롬프트를 더 잘 만드세요"보다 더 날카로운 목표입니다. 왜냐하면 정확히 언제 치는지 그리고 정확히 언제 회귀하는지 볼 수 있기 때문입니다.

실제 사용자가 보기 전에, 다음 장, 안전 및 제한, 설계할 위험을 다룹니다.

Juno실전에서 조랑마는 느낌을 이동할 수 있는 숫자로 바꿉니다: 세트를 실행하고, 점수와 실패를 읽고, 가장 싼 실제를 고치고, 다시 실행합니다. 각 실패는 명확한 완료 정의가 있는 작업입니다. 그것이 "더 좋게 만드세요"보다 더 날카로운 목표입니다. 그러면 실제 사용자가 보기 전에 안전 및 제한합니다.

프로덕션에서 그 작은 조랑마는 손으로 실행하는 스크립트가 되지 않고 시스템의 일부가 됩니다. 점수가 설정한 선 아래로 떨어질 때 배포를 차단하는 CI 게이트와, 릴리스 전체에서 시계할 대시보드로 성장합니다. 단일 실행이 나타나지 않는 느린 표류를 잡으려면.

오프라인 평가, 배포 전에 채점하는 고정 세트, 온라인 모니터링, 실제 트래픽에서 수집하는 신호, 서로를 피드합니다: 프로덕션 실패는 새로운 오프라인 경우가 되고, 오프라인 세트는 수정이 유지되었는지 알려줍니다. 여기서 승리하는 팀은 가장 똑똑한 프롬프트를 가진 팀이 아닙니다. 다른 사람이 눈으로 본 동안 측정한 팀입니다.

그것이 규율입니다. 다음 장, 안전 및 제한, 실제 사용자가 도착하기 전에 설계할 위험을 다룹니다.

Juno실전에서 이를 성숙하게 하면 스크립트는 CI 게이트와 대시보드가 되고, 오프라인 평가와 온라인 모니터링이 서로를 피드합니다. 나는 "내게 좋아 보인다"로 배포했다가 나중에 비용을 지불했으므로, 나로부터 가져가세요: 팀이 측정한 동안 승리한 것은 눈으로 본 것입니다. 실제 사용자가 도착하기 전에 안전 및 제한을 읽으세요.