AI 예시 프롬프트 선택 기준: 대표성·경계 사례·비교 실험

예시 문장의 말투와 형식이 맞아도 새로운 입력의 판단이 틀릴 수 있습니다. 예시가 보여 줄 규칙과 예외를 구별하고, 서로 다른 예시 묶음을 같은 검증 입력으로 비교하는 방법을 설명합니다.

지난 보고서 세 편을 보여 주고 새 보고서를 맡겼는데, 문장 모양은 닮았어도 새 자료에 없는 결론이 들어갈 수 있습니다. 앤트로픽(Anthropic)의 예시 사용 지침은 실제 과제와 가까운 예시, 경계 사례를 포함한 다양성, 지시와 구분되는 구조를 권합니다. 예시에 반복된 특징이 모두 원하는 규칙인지는 따로 점검할 대상입니다.

좋은 예시를 고르려면 무엇을 복사하게 할지 먼저 정합니다. 문체를 보여 주는 자료와 사실 판단을 가르치는 자료는 같은 문서 안에 있어도 역할이 다릅니다. 예시의 분량보다 그 차이를 알아볼 수 있게 주었는지가 선택의 기준이 됩니다.

예시에는 내용과 형식 외에 판단 규칙도 들어 있습니다

예시에는 완성된 답의 모양, 입력에 따라 고른 답, 답에 남긴 근거가 함께 들어 있습니다. 출력이 세 문장이라는 형식, 사실과 의견을 구분하는 기준, 자료가 없을 때 보류하는 행동을 따로 적으면 예시의 역할이 분명해집니다.

Min 등의 2022년 연구는 조사한 분류·객관식 과제에서 예시가 제시하는 라벨의 범위, 입력의 분포, 전체 형식이 수행에 기여한다고 분석했습니다. 이 결과의 대상은 논문에서 조사한 모델과 과제입니다. 최신 모델의 모든 업무에서 예시 정답의 정확성이 중요하지 않다는 결론으로 확대할 수는 없습니다.

업무 문서를 예시로 주는 경우에도 배울 부분과 가져오면 안 되는 사실을 구분할 수 있습니다. ‘소제목의 순서와 문장 길이만 참고하고 고객명·성과 수치·판단은 새 자료에서 가져온다’는 식입니다. 과거 문서에 있던 긍정적인 결론까지 새 문서에 이어 쓰는 것은 형식 참고의 범위를 벗어납니다.

예시와 실제 입력의 경계도 드러냅니다. 예시 묶음, 적용할 규칙, 이번 입력을 각각 표시하면 어느 텍스트에 답해야 하는지 확인하기 쉽습니다. 예시의 출력이 길고 실제 입력은 한 줄인 경우에는 마지막에 들어온 예시의 답을 이어 쓰는 오류가 없는지도 점검합니다.

대표성은 판단 조건이 다른 입력으로 확인합니다

실제로 들어올 입력이 모두 쉬운 문장이라면 쉬운 예시부터 시작할 수 있습니다. 부정문, 정보 누락, 같은 안건에 대한 상충 기록이 들어오는 업무라면 그런 입력을 구별하는 예시도 필요합니다. 문장의 주제나 사람 이름만 바꾼 사례 여러 개는 판단 조건의 다양성을 충분히 늘리지 못합니다.

대표성에는 자주 나오는 유형과 놓쳤을 때 영향이 큰 유형이 함께 들어갑니다. 빈도만 따르다 드문 보류 조건을 빼면, 자료가 없는데도 답을 확정하는 오류를 발견하기 어렵습니다. 반대로 모든 예시가 특수한 예외라면 평범한 입력에서 기대하는 행동이 잘 드러나지 않습니다.

Liu 등의 GPT-3 예시 선택 연구는 검증 입력과 의미상 비슷한 예시를 검색하는 방식을 연구하고, 조사한 언어 이해·생성 과제에서 무작위 선택과 비교했습니다. 이 연구는 과제와 관련 있는 예시를 고르는 근거가 됩니다. 글의 주제어가 같다는 이유만으로 새로운 업무의 경계 조건까지 같다고 판단할 근거는 별도로 필요합니다.

‘채택하지 않기로 합의했다’와 ‘채택하면 좋겠다’는 같은 안건의 단어를 공유해도 결정 상태가 다릅니다. 회의 메모를 분류한다면 이 차이가 예시 선택에 필요합니다. 반대로 서로 다른 안건이라도 명시적으로 합의했다는 구조가 같으면 같은 판단 규칙을 보여 줍니다.

규칙 충돌과 우연한 패턴을 나누어 진단합니다

같은 입력에 서로 다른 정답을 붙인 예시는 먼저 규칙을 확인할 대상입니다. ‘보류로 합의했다’를 어떤 예시에서는 결정, 다른 예시에서는 확인 필요로 처리했다면 정의가 맞지 않을 수 있습니다. 문장만 다듬어서는 두 답의 충돌이 해소되지 않습니다.

우연한 패턴은 정답과 상관없는 특징이 한쪽 답에만 몰린 경우입니다. 긴 문장이 모두 높은 우선순위이고 짧은 문장은 모두 낮은 우선순위라면, 길이와 판단 기준이 함께 움직입니다. 새 입력에서 판정이 틀렸을 때 의도한 규칙과 길이 중 무엇을 따랐는지 구분하기 어려워집니다.

다음 표는 예시를 다시 고를 때 볼 진단 항목입니다. 실제 특정 모델에서 관측한 오류 목록이 아니라 원인을 분리하기 위한 점검표입니다.

발견한 특징	확인할 가설	예시를 바꾸는 방향
모든 예시의 정답이 같은 라벨	답의 범위가 충분히 드러나지 않음	다른 라벨과 보류 조건을 추가
입력이 다른데 출력의 고유명사가 반복	예시 내용의 복사가 섞임	복사 가능한 형식과 새 자료에서 가져올 사실을 명시
비슷한 입력에 정답이 다름	규칙 충돌 또는 설명 없는 예외	우선 규칙·예외를 정하고 정답을 통일
긴 입력만 특정 라벨	길이와 라벨의 우연한 결합	길이는 비슷하고 판단은 다른 예시를 포함
예시마다 출력 필드가 다름	형식 자체가 일관되지 않음	필드·값의 종류·누락 표현을 맞춤

구글의 예시 프롬프트 지침은 예시의 구조와 형식을 일관되게 유지하도록 설명합니다. 필드 이름, 줄바꿈, 예시 구분자가 서로 다르면 형식 오류의 원인을 내용의 부족과 나누어 봐야 합니다. 형식을 고친 뒤에도 판단이 틀리는지 확인하면 다음 수정 대상을 좁힐 수 있습니다.

예시만 바꾸는 비교를 재현 가능한 형태로 만듭니다

아래는 회의 메모의 결정 상태를 판정하는 가상 실험 설계입니다. A는 결정 사례만, B는 서로 다른 판정과 정보 부족을 보여 줍니다. 모델 실행은 하지 않았으며 어느 묶음이 더 낫다는 결과 수치는 없습니다.

두 조건에 다음 지시를 동일하게 사용합니다. 예시를 줄 위치에는 A 또는 B 중 한 묶음만 넣습니다. 검증 표의 정답과 판정 이유는 모델에 보내지 않습니다.

markdown복사

회의 메모 하나의 안건 상태를 분류해 줘.
라벨은 결정 / 제안 / 확인필요 중 하나만 사용해.
결정: 채택·기각·보류 등을 합의하거나 확정했다고 명시한 경우.
제안: 의견이나 요청을 제시했고, 합의·확정했다는 기록이 없는 경우.
확인필요: 판정할 근거가 부족하거나, 같은 안건의 상충 기록을 선후 관계로 해소할 수 없는 경우.
반환 형식: {"status":"라벨","evidence":"입력에서 그대로 가져온 근거 구절"}
evidence는 이번 입력의 연속된 구절로 써 줘. 예시의 사실과 문장은 이번 입력에 섞지 마.

예시 묶음 A에는 다음 세 쌍을 사용합니다.

json복사

[
  {"input":"A안으로 진행하기로 합의했습니다.","output":{"status":"결정","evidence":"A안으로 진행하기로 합의했습니다."}},
  {"input":"수요일 시행하기로 결정했습니다.","output":{"status":"결정","evidence":"수요일 시행하기로 결정했습니다."}},
  {"input":"공유 범위는 팀 안으로 한정하기로 정했습니다.","output":{"status":"결정","evidence":"팀 안으로 한정하기로 정했습니다."}}
]

예시 묶음 B는 첫 쌍을 유지하고 나머지 두 쌍을 바꿉니다.

json복사

[
  {"input":"A안으로 진행하기로 합의했습니다.","output":{"status":"결정","evidence":"A안으로 진행하기로 합의했습니다."}},
  {"input":"시행일을 수요일로 옮기자는 의견이 나왔습니다.","output":{"status":"제안","evidence":"옮기자는 의견이 나왔습니다."}},
  {"input":"공유 범위는 담당자에게 확인이 필요합니다.","output":{"status":"확인필요","evidence":"공유 범위는 담당자에게 확인이 필요합니다."}}
]

검증 입력은 예시와 겹치지 않게 고정합니다. 정답은 이 실험의 지시문에 적은 정의에 따라 미리 정한 판정입니다. T08처럼 상충 기록을 넣은 항목은 모델 출력을 보기 전에 왜 확인이 필요한지 합의해 둡니다.

ID	검증 입력	정답	판정 이유
T01	참석자 전원이 B안 채택에 동의했고 B안으로 확정했다.	결정	명시적 확정
T02	B안을 채택하자는 의견이 나왔다.	제안	제안만 기록
T03	결론 부분은 비어 있고 담당자 확인이 필요하다고만 적혀 있다.	확인필요	판정 근거 부족
T04	A안은 채택하지 않기로 참석자들이 합의했다.	결정	기각에 대한 합의
T05	제목은 결정안이지만 본문에는 참석자의 확정 발언이나 제안 내용이 없다.	확인필요	제목만으로 결정·제안을 판정할 수 없음
T06	이전 결정은 수요일 시행이었다. 이번 회의에서는 금요일로 변경하기로 합의했다.	결정	이전 기록과 새 합의의 선후가 명확
T07	정해진 안은 없다. 예산을 검토한 뒤 A안을 제안한다.	제안	제안과 미확정을 명시
T08	한 메모에는 A안 합의, 다른 메모에는 같은 안건 미정이라고 적혀 있다. 두 메모의 선후는 알 수 없다.	확인필요	상충 기록의 우선순위 불명

실행할 때는 모델 이름과 정확한 버전 또는 식별자, 사용 서비스, 생성 설정, 실행 날짜, 예시 순서, 전체 입력과 출력을 저장합니다. 각 검증 입력은 새 대화에서 시작하고 A·B가 같은 이전 대화의 영향을 받지 않게 합니다. 두 묶음의 길이가 다르므로 가능하면 입력 사용량도 기록합니다. 길이의 효과까지 따로 알아보려면 예시 길이를 맞춘 후속 조건이 필요합니다.

예시 설계 단계에서 반복 횟수도 고정합니다. 이 비교에서는 각 조건·입력을 세 번씩 실행하도록 정할 수 있습니다. 한 번의 우연한 성공을 결과로 확정하지 않기 위한 소규모 비교이며, 이 횟수가 모든 업무에 충분하다는 뜻은 아닙니다. 모델·설정·예시를 동시에 바꾸면 차이의 원인을 예시 선택으로 좁히기 어렵습니다.

총점보다 새 입력에서 반복되는 실패를 봅니다

판정은 라벨 정답, 형식, 근거 구절을 나눕니다. 라벨은 맞아도 출력 필드가 빠졌거나 근거에 예시의 문장을 복사했다면 다른 종류의 실패입니다. evidence가 검증 입력의 실제 연속 구절인지도 별도로 대조합니다.

결과 기록에는 조건 A·B, 입력 ID, 반복 번호, 반환 원문, 라벨 정오, 형식 충족, 근거 일치, 사람의 판정 메모를 남깁니다. 합계가 비슷해도 T04의 부정문이나 T08의 충돌에서 반복적으로 틀리는지 볼 수 있습니다. 이 항목별 기록이 다음 예시에서 무엇을 보여 줄지 정하는 자료가 됩니다.

수정 순서는 규칙 충돌, 형식 불일치, 빠진 판단 유형, 불필요한 예시 내용의 순서로 정할 수 있습니다. 여러 문제가 섞인 예시를 한꺼번에 늘리면 어떤 수정이 차이를 만들었는지 알기 어려워집니다. 이미 잘 처리하는 입력도 남겨 두어 새 예시를 넣은 뒤 다른 유형이 나빠지는지 함께 확인합니다.

예시로 쓴 입력과 검증 입력을 분리하고, 실패한 유형을 대표하는 예시를 하나씩 보완하는 편이 좋습니다. 고른 예시를 영구 정답 세트로 두기보다는 실제 입력의 종류가 바뀔 때 경계 사례와 보류 조건도 다시 대조합니다.

자료 확인 기준: 2026년 10월 28일 UTC. 문헌의 관측 범위와 이 글의 미실행 비교 설계를 구분했습니다.

예시 프롬프트의 기본 형식과 다른 기법