우리는 수동으로 평가 케이스(eval cases)를 작성하는 것을 중단했습니다. 이제 모든 운영 환경 장애(prod incident)가 하나의

요약(TL;DR): 수동으로 작성된 평가 케이스(eval cases)는 이미 상상했던 실패들을 테스트하며, 그런 실패들은 결코 당신을 호출(page)하게 만들지 않습니다. 우리가 가진 최고의 평가 케이스는 브레인스토밍에서 나온 것이 아니라, 운영 환경 장애(production incidents)에서 나왔습니다. 우리는 사후 분석(postmortem) 프로세스가 자동으로 평가 케이스를 생성하도록 연결했으며, 그 결과 우리의 평가 세트(eval set)는 우리가 이미 저지르지 않고 있던 버그 대신 지난달 장애의 다음 변종을 잡아내기 시작했습니다.

수동으로 작성된 평가 세트(eval sets)는 당신의 상상력 모양의 사각지대를 가집니다

평가 케이스(eval cases)를 작성하기 위해 앉았을 때, 당신은 생각할 수 있는 실패들을 작성하며, 정의상 그것들은 당신이 이미 방어하고 있는 것들입니다. 운영 환경(prod)을 무너뜨리는 실패는 아무도 상상하지 못한 것이며, 당신의 수동 작성 세트에는 들어있지 않습니다. 만약 당신이 그것을 상상했다면 이미 수정했을 것이기 때문입니다. 따라서 평가(eval) 결과가 '그린(green)'으로 나온다는 것은 당신이 여전히 이미 알고 있던 실수들을 저지르지 않고 있다는 것을 주로 알려줄 뿐입니다.

장애(incidents)로부터 케이스 채굴하기

모든 운영 환경 장애(prod incident)는 당신에게 무료로 제공되는 라벨링된 예시(labeled example)입니다: 입력값(input), 잘못된 출력값(wrong output), 그리고 그것이 잘못되었다고 이미 결정한 사람입니다. 우리는 정확한 입력 엔벨로프(input envelope: 프롬프트(prompt), 검색된 컨텍스트(retrieved context), 도구 출력(tool outputs), 모델(model) 및 파라미터(params))와 수정된 예상 동작을 캡처하도록 사후 분석(postmortem) 템플릿을 변경했으며, 작은 스크립트가 이를 영구적인 케이스로서 평가 세트(eval set)에 삽입합니다.

# 사후 분석(postmortem) 종료 시, 장애를 영구적인 평가 케이스(eval case)로 캡처
def incident_to_eval_case(incident):
    return {
...

두 가지가 변했습니다. 평가 세트(eval set)는 우리가 상상한 방식이 아니라 시스템이 실제로 실패하는 방식을 반영하기 시작했습니다. 그리고 "회귀 테스트(regression test)를 추가하라"는 말이 누군가 잊어버리는 별도의 작업이 아니라, 사후 분석(postmortem)의 한 필드가 되어 매번 수행되게 되었습니다.

정직한 한계

정직한 한계

이것은 구조적으로 반응적(reactive)입니다. 장애(incident)가 발생한 후에야 케이스를 얻을 수 있으므로, 아직 발생하지 않은 실패에 대해서는 아무런 역할을 하지 못합니다. 우리는 무섭지만 아직 보지 못한 클래스(classes)들을 위해 소수의 수동 작성된 적대적 케이스(adversarial cases)를 함께 사용하지만, 가치의 대부분과 실제로 반복되는 회귀(regressions)를 잡아내는 케이스들은 장애(incidents)로부터 나옵니다.

미해결 과제 (Open question)

장애에서 유도된 케이스는 하나의 예시일 뿐입니다. 실제 실패는 보통 하나의 클래스(CLASS)이며, 그와 유사한 형태를 가진 모든 입력값입니다. 수동으로 변형을 작성하지 않고 단일 장애를 해당 클래스 전체를 위한 생성기(generator)로 전환하는 부분은 제가 아직 제대로 자동화하지 못한 부분입니다. 만약 하나의 장애로부터 그와 동등한 클래스(equivalence class)의 평가 케이스(eval cases)로 넘어가는 깔끔한 방법을 알고 계신다면, 그것이 바로 제가 듣고 싶은 의견입니다.