Quick Flow
metaprompting은 ChatGPT에게 "더 좋은 prompt"를 막연히 만들어 달라고 하는 일이 아니라, 기존 prompt와 재현 가능한 failure를 기준으로 변경 가설을 만드는 방법입니다. 원본·목표·실제 output·변경 금지 범위·test case를 주고, 수정안마다 바뀐 문장과 예상 trade-off를 받습니다. 최종 판정은 같은 holdout input을 실행한 결과로 합니다.
baseline prompt + failing input + observed output
-> failure를 한 문장으로 정의
-> 최소 수정안 A/B 제안
-> 동일한 holdout suite에서 비교
-> pass 조건을 만족한 변경만 채택원본 prompt: <prompt>...</prompt>
목표: `severity`, `evidence`, `next_action`을 빠짐없이 반환
실패: 경계 input에서 evidence 없이 severity를 단정
변경 금지: output JSON key와 source 범위
요청: 수정안마다 diff, 해결하려는 failure, 새 risk, test case를 제시수정안을 읽는 기준
좋은 수정안은 "더 구체적으로 써라" 같은 조언이 아니라 어느 block을 왜 고치는지 보입니다. task가 모호한지, input boundary가 없는지, output contract가 약한지, example이 boundary case를 덮지 못하는지를 분리합니다. 기존에 정상인 behavior까지 바꾸지 않도록 최소 변경 원칙을 둡니다.
| 관찰된 failure | 우선 의심할 block | 수정안에 필요한 증거 |
|---|---|---|
| 사실을 추정함 | source 범위·unknown fallback | source 없는 input에서 보류하는지 |
| field가 빠짐 | output contract·schema | required field validator 통과 |
| label이 경계에서 뒤집힘 | decision rule·example | holdout boundary case 통과 |
| 너무 길거나 짧음 | scope·length constraint | 내용 coverage를 해치지 않는지 |
| tool이 엉뚱하게 실행됨 | trigger·approval·permission | denied action이 실제로 막히는지 |
평가로 닫기
ChatGPT가 제안한 수정안을 정답으로 처리하지 않습니다. baseline과 candidate prompt를 같은 normal·boundary·safety input에 실행하고, accuracy·format violation·latency·human escalation을 비교합니다. candidate를 만들 때 사용한 failure 사례는 설명용이고, 최종 평가는 그 사례를 제외한 holdout set에서 합니다.
메타프롬프트는 prompt의 문장을 개선할 수 있어도 최신 source, tool 권한, parser, business rule을 자동으로 고쳐 주지 않습니다. 제품 failure의 원인이 model 선택·retrieval·API 설정·권한에 있으면 prompt만 바꾸지 말고 해당 layer를 수정합니다.
참고 링크
1 sources