01 · THE QUESTION
같은 모델이 더 좋은 답을 냈다면 prompt가 좋아진 걸까
한 번의 응답만 놓고는 알 수 없습니다. 질문이 쉬웠을 수 있고, sampling variance가 우연히 유리했을 수 있으며, 더 길어진 답을 더 좋은 답으로 착각했을 수도 있습니다. Prompt를 개선했다는 말에는 비교 가능한 조건과 반복 가능한 평가가 필요합니다.
02 · EXPERIMENT
비교 실험의 최소 조건을 고정합니다
| 통제 항목 | 왜 필요한가 |
|---|---|
| Dataset | 서로 다른 prompt가 같은 문제 묶음을 풀어야 비교할 수 있습니다. |
| Model / provider | Model 변경 효과가 prompt 효과에 섞이지 않게 합니다. |
| Sampling | Temperature, seed, max token 차이에서 생긴 variance를 줄입니다. |
| Tool / retrieval state | 검색 index와 도구 결과가 같아야 prompt만 비교할 수 있습니다. |
| Rubric | ‘좋다’ 대신 정확성, 근거, 형식, 안전성처럼 관찰 가능한 기준을 씁니다. |
| Repetition | 한 번의 luck이 아니라 분포와 실패율을 봅니다. |
LLM 평가는 답을 보고, Agent 평가는 trajectory도 봅니다
일반 생성 과제라면 최종 답의 정확성과 품질이 중심입니다. Agent에서는 올바른 tool을 골랐는지, argument가 유효했는지, 불필요한 step이 몇 번 있었는지, 위험한 행동 전에 승인을 요청했는지까지 평가해야 합니다.
03 · EVAL SHEET
작은 표 하나로 감상을 데이터로 바꿉니다
| 필드 | 기록 예시 |
|---|---|
| case_id | support_014 |
| prompt_version | support-answer@1.3.0 |
| model_config | provider / model / temperature |
| expected | 필수 사실, 금지 행동, 출력 contract |
| actual | 응답, tool trajectory, latency, token |
| scores | correctness, groundedness, format, safety |
| failure_label | instruction miss / retrieval miss / tool misuse |
평균 점수만으로는 어느 사용자가 실패하는지 알기 어렵습니다. Case를 질문 유형과 난이도, 언어, tool 필요 여부로 slice하고 최악의 실패를 함께 읽어야 합니다.
04 · ASSET
Prompt를 문자열이 아니라 배포 가능한 자산으로 관리합니다
PROMPT MANIFEST
id: support-answer
version: 1.3.0
owner: agent-platform
inputs: [question, retrieved_context]
output_schema: SupportAnswerV2
allowed_tools: [search_policy]
eval_dataset: support-regression@2026-07
change_note: tighten citation and uncertainty rulesPrompt 파일에는 id와 version, owner, input/output contract, 허용 tool, 연동된 evaluation set, 변경 이유가 있어야 합니다. 그래야 실패한 production run에서 어떤 prompt가 사용됐는지 찾고 이전 version과 비교할 수 있습니다.
길이는 품질의 대리 지표가 아닙니다
지시를 계속 덧붙이면 일시적으로 한 case가 좋아질 수 있지만, instruction conflict와 token 비용, 중요한 규칙의 희석이 함께 커집니다. 중복 규칙은 합치고, 안정적인 prefix와 요청별 dynamic tail을 분리하며, example은 실제 failure mode를 설명할 때만 남깁니다.
05 · JUDGING
자동 평가도 다시 평가해야 합니다
Schema validation, exact match, tool argument 검사처럼 deterministic하게 확인할 수 있는 것은 code로 먼저 평가합니다. 의미 품질은 rubric 기반 LLM judge를 사용할 수 있지만, verbosity bias와 self-preference, rubric ambiguity를 경계해야 합니다.
- Judge prompt와 model version도 실험 metadata로 남깁니다.
- Human label과 judge가 자주 엇갈리는 slice를 calibration set으로 만듭니다.
- 전체 평균뿐 아니라 safety regression과 critical case는 별도 gate로 둡니다.
- 변경 전후 latency와 token cost도 quality와 함께 비교합니다.