8장. 좋은 예시는 스타일이 아니라 기준을 전달한다

예시는 모델에게 원하는 결과의 모양을 보여 준다. 그러나 예시가 많다고 항상 좋지 않다. 불필요한 문구를 따라 하거나 특정 사례에 과적합하고 입력 비용도 늘어난다. 예시는 측정된 실패를 고칠 때 넣는다.

좋은 예시는 입력, 좋은 출력, 이유를 한 세트로 둔다.

입력 사실: 비용 상한 추정 48만원, 실제 청구액 아님

나쁜 출력: 월 비용은 48만원이다.
좋은 출력: 베타 100명 가정에서 월 변동비 상한은 48만원으로 추정된다 [SRC-03].
이유: 가정과 불확실성을 보존했고 출처를 표시했다.

반례도 중요하다. 숫자는 맞지만 단위를 잃은 답, 출처는 붙였지만 다른 주장을 지지하는 답, 형식은 맞지만 반대 조건이 없는 답을 보여 준다. 모델과 사람 평가자가 무엇을 실패로 볼지 구체화된다.

예시에는 실제 고객 이름이나 문서를 넣지 않는다. 패턴만 보존한 합성 fixture를 만든다. 원문의 구조를 그대로 복제해야 한다면 이용 권한과 보존 정책을 확인한다.

예시를 추가한 뒤 같은 평가 세트로 전후를 비교한다. 평균 점수가 올라도 특정 예시와 비슷한 사례만 좋아졌다면 일반화가 아니다. holdout 사례를 따로 둔다.

실전 규칙은 간단하다. 처음에는 지시와 자료만으로 실행한다. 반복되는 오류를 세 개 이상 모은다. 그 오류를 가장 짧게 고치는 예시 하나를 추가한다. 개선되지 않으면 예시가 아니라 모델, 자료, 도구, 평가 문제인지 다시 본다.

예시 과적합을 확인한다

예시의 회사명, 숫자, 문장 순서를 바꾼 변형 사례를 실행한다. 모델이 예시의 48만원을 다른 비용 사례에도 복사하면 실패다. 예시에는 고정 값을 따라 쓰지 말고 어떤 근거에서 어떤 변환을 했는지 드러낸다.

나쁜 예시 규칙: 비용은 48만원이라고 쓴다.
좋은 예시 규칙: source의 값·가정·단위를 보존하고 source_id를 붙인다.

좋은 결과 하나뿐 아니라 경계 사례를 포함한다. 근거가 없을 때는 UNKNOWN, 출처가 충돌하면 CONFLICT, 외부 행동이면 APPROVAL_REQUIRED가 되는 예시를 하나씩 둔다. 모델이 거절과 보류를 정상 출력으로 배우게 한다.