Self-Supervised Prompt Optimization Review

0. Introduction

Paper link

Official code

Self-Supervised Prompt Optimization, SPO는 prompt optimization을 조금 다른 각도에서 본다. 기존 prompt optimization은 보통 gold label, benchmark score, human feedback, 혹은 explicit textual critique를 사용해서 prompt를 고친다. 그런데 실제 서비스 환경에서는 이런 reference가 항상 있지 않다. 특히 writing, roleplay, summarization, agent instruction, document processing처럼 정답이 하나로 고정되지 않는 task에서는 prompt를 어떻게 평가할지가 더 어려운 문제가 된다.

이 논문의 핵심은 이 지점을 “reference-free prompt optimization”으로 바꾸는 것이다. SPO는 prompt가 좋은지 직접 점수화하지 않는다. 대신 서로 다른 prompt가 만든 output을 LLM judge가 pairwise로 비교하게 하고, 더 좋은 output을 만든 prompt를 다음 iteration의 기준 prompt로 채택한다. 즉 label이 아니라 output 자체가 evaluation reference이자 optimization guidance가 된다.

한 줄 요약: SPO는 gold label이나 human feedback 없이, LLM output pairwise comparison만으로 prompt를 반복 개선하는 reference-free prompt optimization framework다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

• prompt optimization을 supervised validation problem이 아니라 output comparison problem으로 재정의한다.
• closed task와 open-ended task를 같은 loop 안에서 처리한다.
• 3개 sample과 10 iteration이라는 작은 budget으로도 prompt search가 가능한 practical recipe를 제시한다.
• LLM-as-a-judge를 단순 evaluation report가 아니라 optimization loop 내부의 selection signal로 쓴다.
• 실무적으로 prompt engineering, agent instruction tuning, domain-specific response formatting에 바로 연결하기 좋다.

이 논문에서 중요한 점은 성능 수치 자체보다 가정의 변화다. 기존 방식은 좋은 prompt를 찾기 위해 정답이나 외부 reference가 필요하다고 본다. SPO는 prompt의 quality가 결국 output에 나타난다면, output끼리 비교하는 것만으로도 prompt optimization signal을 만들 수 있다고 본다. 이 가정은 완벽하지 않지만, label이 부족한 실제 업무에서는 꽤 쓸모 있는 출발점이다.

1. Problem Setting

1-1. Problem definition

이 논문이 겨냥하는 문제는 “automatic prompt optimization”이다.

일반적인 prompt optimization은 task type $t$에 대해 candidate prompt $P_t$를 고르고, execution model이 query $Q$와 prompt $P_t$를 받아 output을 만든 뒤, evaluation function이 output quality를 평가하는 loop다. 원문의 목적 함수는 개념적으로 아래처럼 볼 수 있다.

\[P_t^* = \arg\max_{P_t \in P} \mathbb{E}_{(Q,G) \sim D_t} [ \phi_{eval}(\phi_{exe}(Q, P_t), G) ]\]

여기서 $G$는 optional ground truth다. 중요한 점은 optional이라는 표현이다. 실제 많은 task에서는 $G$가 없거나, 있더라도 비용이 크거나, 하나의 정답으로 고정하기 어렵다.

그래서 이 논문이 묻는 질문은 다음과 같다.

• ground truth 없이 prompt quality를 어떻게 평가할 것인가.
• open-ended task에서도 prompt optimization을 자동화할 수 있는가.
• 많은 sample을 쓰지 않고도 optimization signal을 만들 수 있는가.
• prompt candidate의 개선 여부를 LLM output만 보고 판단할 수 있는가.

이 문제는 prompt engineering 자동화에서 꽤 실무적이다. Label이 있는 classification benchmark라면 prompt별 accuracy를 계산하면 된다. 하지만 실제 product task는 evaluation set이 없거나, 요구사항이 style, format, coverage, faithfulness, safety처럼 복합적이다. 이 경우 prompt optimization은 결국 task requirement를 얼마나 잘 만족하는 output을 만드는지 비교하는 문제에 가까워진다.

1-2. Why previous approaches are insufficient

기존 prompt optimization은 크게 두 방향으로 볼 수 있다.

1. Benchmark 또는 ground truth 기반 방법

APE, OPRO, PromptAgent, PromptBreeder 같은 방법은 candidate prompt를 만들고, training 또는 validation sample에서 score를 계산한다. 이 방식은 closed task에서는 깔끔하지만, label이 없는 task나 open-ended generation에서는 적용하기 어렵다. 또 많은 prompt와 많은 sample을 평가해야 하므로 비용이 커진다.

1. Human feedback 또는 textual gradient 기반 방법

Human feedback은 품질이 높지만 느리고 비싸다. TextGrad처럼 LLM feedback을 textual gradient로 쓰는 방식도 있지만, 여전히 평가 signal 구성과 prompt update가 복잡하고 비용이 커질 수 있다.

SPO가 겨냥하는 빈틈은 여기다. 실제 업무에서는 label도 부족하고, human evaluator도 계속 붙이기 어렵고, prompt search에 큰 budget을 쓰기도 어렵다. 그런데 LLM은 이미 response quality를 어느 정도 비교할 수 있다. 그렇다면 output끼리 비교해서 prompt를 선택하면 되지 않을까? 이게 SPO의 출발점이다.

2. Core Idea

2-1. Main contribution

SPO의 핵심 기여는 다음 3가지로 정리할 수 있다.

1. Output as pairwise evaluation reference

SPO는 candidate prompt의 output과 현재 best prompt의 output을 pairwise로 비교한다. 외부 정답과 output을 비교하는 Output vs Ground Truth, OvG가 아니라 output끼리 비교하는 “Output vs Output”, OvO를 쓴다.

1. Output as optimization guidance

Prompt optimizer는 현재 best prompt와 그 prompt가 만든 output을 보고 새로운 prompt를 만든다. 즉 optimizer가 받는 signal은 explicit score나 gold feedback이 아니라, 현재 prompt가 어떤 output을 냈는지에 대한 사례다.

1. Low-cost “Optimize-Execute-Evaluate” loop

SPO는 3개 sample을 뽑고, prompt를 실행하고, output pairwise comparison으로 candidate를 채택할지 결정한다. 논문은 running example 기준으로 iteration당 8번의 LLM call이 필요하다고 설명한다. Main experiment는 10 iteration으로 진행된다.

이 구조의 장점은 단순하다. Prompt optimization을 위해 별도 reward model을 학습하지 않고, human feedback도 요구하지 않는다. 필요한 것은 task requirement, initial prompt, 소수의 sample, 그리고 optimizer, executor, evaluator 역할을 하는 LLM들이다.

2-2. Design intuition

이 논문의 설계 직관은 두 문장으로 요약할 수 있다.

• 좋은 prompt는 좋은 output을 만든다.
• LLM은 두 output 중 어느 쪽이 task requirement를 더 잘 만족하는지 비교할 수 있다.

이 두 가정을 합치면 prompt optimization이 가능해진다. Prompt 자체를 직접 비교하지 않고, prompt가 만든 output을 비교하면 된다. Output이 더 좋으면 그 output을 만든 prompt도 현재 context에서는 더 좋은 prompt라고 본다.

다만 여기에는 중요한 주의점이 있다. Pairwise judge는 ground truth가 아니다. 특히 specialized domain, factual verification, legal/medical/finance 같은 high-stakes task에서는 judge model이 그럴듯한 output을 선호할 수 있다. 그래서 SPO는 label-free optimization을 가능하게 하지만, final evaluation까지 label-free로 끝내도 된다는 뜻은 아니다.

SPO의 진짜 가치는 self-improving prompt loop가 아니라, reference가 부족한 상황에서 initial candidate를 빠르게 끌어올리는 low-cost search procedure에 있다. 완전 자동화보다 human review 전 단계의 prompt pre-optimization으로 쓰는 편이 더 안전하다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	external reference 없이 prompt를 반복 개선
Core framework	Optimize-Execute-Evaluate loop
Evaluation source	LLM-generated outputs
Evaluation method	LLM-as-a-judge pairwise comparison
Feedback type	rank or selection signal
Main sample budget	3 samples per iteration
Main iteration budget	10 iterations
Key risk	judge bias, sample overfitting, domain mismatch

SPO는 model architecture 논문이 아니다. Prompt optimization을 위한 orchestration framework에 가깝다. 구성 요소는 optimizer, executor, evaluator의 세 함수다.

3-2. Module breakdown

1) Optimization function

Optimization function, $\phi_{opt}$는 현재 best prompt와 그 prompt가 만든 output들을 입력으로 받아 revised prompt를 만든다.

원문의 optimizer prompt는 대략 이런 역할을 한다.

• current prompt가 만든 output의 단점을 분석한다.
• task requirement를 더 잘 만족하기 위한 modification point를 제안한다.
• 완성된 optimized prompt를 XML 형태로 출력한다.

여기서 중요한 점은 optimizer가 ground truth error를 받지 않는다는 것이다. 예를 들어 수학 문제에서 정답이 틀렸다는 label을 받는 것이 아니라, 현재 prompt가 만든 output 사례를 보고 더 나은 prompt를 제안한다. 그래서 optimizer의 품질은 optimization model이 task requirement와 output defect를 얼마나 잘 이해하는지에 크게 의존한다.

2) Execution function

Execution function, $\phi_{exe}$는 prompt를 실제 task input에 적용해서 output을 만든다. SPO는 iteration 시작 시 dataset에서 3개 question을 sample로 뽑고, 같은 sample set에 대해 current best prompt와 new prompt를 비교한다.

이 방식은 비용을 줄인다. 모든 training data에 대해 prompt를 평가하지 않고, 작은 sample subset으로 prompt candidate를 빠르게 filter한다. 대신 sample overfitting 위험이 생긴다. 실제로 appendix에서는 sample number가 너무 적으면 overfitting이 발생하고, sample이 너무 많으면 cost와 context length가 늘어 evaluation quality가 떨어질 수 있다고 분석한다.

3) Evaluation function

Evaluation function, $\phi_{eval}$는 두 output을 비교하고 어떤 output이 requirement를 더 잘 만족하는지 선택한다. 선택된 output을 만든 prompt가 다음 round의 best prompt가 된다.

원문은 evaluation prompt가 requirement, answer A, answer B를 입력으로 받고, XML 형태로 analysis와 choice를 반환하게 한다. 이때 position bias를 줄이기 위해 randomized evaluation을 여러 번 수행한다. 논문은 four rounds of randomized evaluation으로 bias를 완전히 제거할 수는 없지만, overall optimization trend에는 큰 영향을 주지 않도록 완화한다고 설명한다.

SPO의 algorithm은 아래처럼 정리할 수 있다.

Initialize P0
Sample 3 questions Q from dataset
Set best prompt P_best = P0
Set best answer A_best = execute(Q, P_best)

for iteration in 1..N_max:
  P_new = optimize(P_best, A_best)
  A_new = execute(Q, P_new)
  success = evaluate(Q, A_new, A_best)
  if success:
    P_best = P_new
    A_best = A_new

return P_best

이 algorithm의 핵심은 state가 prompt만이 아니라 answer도 함께 들고 간다는 점이다. 다음 optimizer는 best prompt와 best answer를 같이 본다. 즉 prompt search가 abstract한 문장 탐색이 아니라 output trace 기반의 iterative refinement가 된다.

4) OvG vs OvO

논문은 evaluation framework를 Output vs Ground Truth, OvG와 Output vs Output, OvO로 구분한다.

OvG는 아래처럼 ground truth $G_i$와 output을 비교한다.

\[f_{OvG} = \phi_{eval}(\phi_{exe}(Q_i, P_t), G_i)\]

반면 SPO의 핵심은 OvO다. Conceptually, candidate prompt들의 output set을 서로 비교한다.

\[f_{OvO} = \phi_{eval}(\{ \phi_{exe}(Q_i, P_i) \})\]

OvO의 장점은 외부 reference가 필요 없다는 점이다. 특히 open-ended task처럼 여러 답이 모두 valid할 수 있는 경우에는 정답과 비교하는 방식보다 output pairwise preference가 더 자연스러울 수 있다.

4. Training / Data / Recipe

4-1. Data

SPO는 별도 model training을 하지 않는다. 대신 prompt optimization loop를 여러 benchmark와 open-ended task에서 평가한다.

Closed task는 다음 5개다.

• GPQA-Diamond
• AGIEval-MATH Level 5
• LIAR
• WSC
• BBH-Navigate

Open-ended task는 MT-Bench에서 writing, roleplay, humanities를 선택한다. MT-Bench는 dataset size가 제한되어 있어서 논문은 이 3개 task에 대해 validation set을 수동 구성했다고 설명한다.

Appendix의 dataset split은 아래처럼 정리된다.

Dataset	Test	Train and Validate
LIAR	461	3681
BBH-Navigate	200	50
WSC	150	50
AGIEval-MATH	256	232
GPQA	198	250
MT-Bench	80	0

여기서 SPO가 실제 optimization에 쓰는 sample은 전체 train and validate set이 아니라 iteration당 3개 sample이라는 점이 중요하다. 그래서 이 논문은 data-rich prompt optimization보다 data-scarce prompt optimization에 더 가깝다.

4-2. Training strategy

SPO 자체에는 gradient update가 없다. 학습되는 것은 model parameter가 아니라 prompt다. 그래서 training strategy라는 표현보다는 prompt optimization recipe라고 보는 편이 맞다.

Main experiment 설정은 다음과 같다.

Role	Model	Temperature	Note
Optimizer	Claude-3.5-Sonnet-20240620	0.7	main SPO setting
Optimizer alternate	GPT-4o-0806	0.7	SPO with GPT-4o optimizer
Evaluator	GPT-4o-mini-0718	0.3	pairwise judge
Executor	GPT-4o-mini-0718	0	task output generation
Iterations	10	-	main setting
Samples	3	-	per iteration

이 구성이 흥미로운 이유는 역할 분리 때문이다. Optimizer는 prompt를 고치는 모델이고, evaluator는 pairwise selection을 하는 모델이며, executor는 실제 task output을 만드는 모델이다. 같은 LLM을 세 역할에 모두 쓸 수도 있지만, 논문은 role별 model choice를 ablation한다.

Code repo의 quick start도 비슷한 구조를 따른다. SPO_LLM.initialize에서 optimizer, evaluator, executor model과 temperature를 지정하고, PromptOptimizer에 workspace, initial round, max rounds, template, project name을 넣어 실행한다. Repo에는 base model mode와 reasoning model mode를 나누는 옵션도 포함되어 있다.

4-3. Engineering notes

SPO를 실제로 적용할 때 중요한 engineering point는 다음과 같다.

1. Requirement를 명확히 써야 한다.

SPO는 output이 requirement를 만족하는지 비교한다. Requirement가 모호하면 judge도 모호한 기준으로 선택한다. 따라서 task prompt보다 requirement spec이 더 중요할 수 있다.

1. Optimization sample과 final test를 분리해야 한다.

SPO는 3개 sample로 prompt를 반복 수정한다. 이 sample에 과적합될 수 있으므로, final evaluation은 반드시 별도 holdout set에서 해야 한다.

1. Pairwise judge는 randomized order가 필요하다.

A/B position bias는 LLM-as-a-judge의 대표적인 문제다. 원문은 randomized evaluation을 여러 번 수행해 완화한다. 실무에서는 judge model 다변화, rubric-based judging, human audit도 고려할 만하다.

1. Output style optimization과 capability improvement를 구분해야 한다.

SPO는 prompt를 바꾸는 방법이다. 모델이 모르는 지식을 배우게 하거나, 근본적인 reasoning flaw를 parameter 수준에서 수정하지는 않는다. 따라서 output format, reasoning trace structure, role adherence, instruction compliance에는 유용하지만, 모델 자체 capability 한계를 넘기는 도구로 해석하면 안 된다.

5. Evaluation

5-1. Main results

Closed task main result는 Table 1에 정리된다. 모든 method는 divided test set에서 GPT-4o-mini로 실행되고, 결과는 3회 평균이다. 아래는 평균 성능과 optimization cost 중심으로 줄인 표다.

Method	Avg Perf	Avg Cost USD	Comment
IO	61.6	-	direct invocation
CoT	63.8	-	conventional prompting
Step-back	65.0	-	conventional prompting
APE	64.8	9.07	prompt optimization
OPRO	66.6	4.51	prompt optimization
PromptAgent	65.0	2.71	prompt optimization
PromptBreeder	64.5	4.82	prompt optimization
TextGrad	63.9	13.14	prompt optimization
SPO	66.9	0.15	Claude-3.5-Sonnet optimizer
SPO with GPT-4o optimizer	66.3	0.12	GPT-4o optimizer

세부 task 기준으로는 SPO가 GPQA에서 43.6, AGIEval-MATH에서 46.1, LIAR에서 67.1, WSC에서 82.0, BBH-Navigate에서 97.2를 기록한다. 평균은 66.9로 표 안에서 가장 높다. 다만 모든 개별 dataset에서 1등은 아니다. 예를 들어 AGIEval-MATH는 Step-back이 47.5이고, LIAR는 OPRO가 67.6이고, WSC는 PromptAgent가 82.7이다. 그래서 이 결과는 SPO가 모든 task를 압도했다기보다, 평균 성능과 cost-efficiency 조합이 좋다고 읽는 편이 맞다.

Cost 측면은 이 논문의 가장 강한 주장이다. SPO는 다른 prompt optimization method 비용의 1.1%에서 5.6% 수준으로 optimization cost를 줄였다고 보고한다. 평균 optimization cost도 dataset당 0.15 USD로 제시된다. 이 숫자는 당시 model price와 setting에 의존하므로 그대로 일반화하면 안 되지만, 많은 sample을 평가하는 benchmark-based prompt search보다 훨씬 작은 loop라는 점은 분명하다.

5-2. What really matters in the experiments

1) 성능보다 중요한 것은 reference-free setting이다

SPO의 claim을 단순히 Avg Perf 66.9로 읽으면 아쉽다. 더 중요한 것은 ground truth-dependent optimization method들과 비교 가능한 수준의 성능을, ground truth 없이 output pairwise comparison으로 만든다는 점이다.

실무 관점에서는 이것이 더 중요하다. Many real tasks do not have cheap labels. 예를 들어 customer support answer style, enterprise report summarization, role-specific agent response, document extraction instruction, reasoning output format 같은 문제는 benchmark score보다 requirement satisfaction이 중요하다. SPO는 이런 task에 맞는 prompt를 label 없이 빠르게 탐색하는 방법을 보여준다.

2) Model role ablation은 생각보다 중요하다

BBH-Navigate에서 optimizer, evaluator, executor model을 바꾼 ablation도 흥미롭다.

Table 2에서는 optimizer를 Claude-3.5-Sonnet으로 고정하고 evaluator와 executor를 바꾼다. GPT-4o-mini가 evaluator이고 GPT-4o-mini가 executor일 때 97.8이 나온다. Llama3-70B executor에서는 Llama3-70B evaluator가 94.2로 높고, Claude-3-Haiku executor에서는 Llama3-70B 또는 GPT-4o-mini evaluator가 82.0을 기록한다.

Table 3에서는 evaluator를 GPT-4o-mini로 고정하고 optimizer와 executor를 바꾼다. GPT-4o-mini optimizer와 GPT-4o-mini executor 조합이 97.8로 가장 높다. Llama3-70B executor에서는 Gemma-3-12B optimizer가 92.0으로 높고, Claude-3-Haiku executor에서는 Claude-3.5-Sonnet optimizer가 89.7로 높다.

이 결과가 말하는 것은 하나다. Prompt optimization에서 가장 큰 모델이 항상 최선의 optimizer나 evaluator인 것은 아니다. Execution model이 어떤 prompt style에 잘 반응하는지가 중요하다. 따라서 production에 적용할 때도 optimizer model만 강하게 고르는 것보다, 실제 serving model 기준으로 prompt를 검증해야 한다.

3) Sample number와 iteration에는 sweet spot이 있다

Appendix는 sample number와 iteration round에 대한 ablation을 제공한다. 결론은 단순하다.

• sample이 너무 적으면 sampled questions에 overfit될 수 있다.
• sample이 너무 많으면 cost가 늘고, evaluation context가 길어져 judge quality가 떨어질 수 있다.
• 논문은 3 samples가 cost-efficiency와 performance 사이의 balance라고 본다.
• iteration을 20 round까지 늘리면 초기에는 개선되지만 이후 degradation이 나타난다.
• Claude-3.5-Sonnet optimizer의 BBH setting에서는 iteration 7에서 95.8%로 peak를 찍고 이후 감소하는 예시가 제시된다.

즉 SPO는 오래 돌릴수록 무조건 좋아지는 search가 아니다. 작은 validation set에 과적합되는 prompt search로 이해해야 한다. 그래서 early stopping과 holdout evaluation이 중요하다.

4) Open-ended task에서의 의미

Open-ended evaluation은 MT-Bench의 writing, roleplay, humanities에서 수행된다. 논문은 Claude-3.5-Sonnet을 optimizer로, GPT-4o-mini를 evaluator로 사용하고, Claude-3.5-Sonnet, DeepSeek-V3, GPT-4o-mini를 execution model로 선택해 5 iteration을 수행한다. 이후 GPT-4o pairwise comparison으로 SPO 전후를 비교한다.

결과는 SPO가 모든 model configuration에서 performance를 개선한다고 보고한다. 특히 작은 모델이 SPO optimized prompt를 사용할 때 더 큰 모델의 IO output을 이기는 경우도 나타난다. 이 대목은 중요하다. Open-ended task에서는 모델 교체보다 prompt interface 개선이 더 비용 효율적인 성능 향상일 수 있기 때문이다.

다만 open-ended result는 judge preference에 크게 의존한다. GPT-4o judge가 선호하는 writing style과 실제 user preference가 다를 수 있으므로, production에서는 user feedback이나 human review와 함께 확인해야 한다.

6. Limitations

1. Evaluation model dependency

SPO는 external reference를 제거하지만, evaluator LLM에 강하게 의존한다. Evaluator가 specialized domain을 제대로 이해하지 못하면 잘못된 prompt를 best로 선택할 수 있다. 특히 factuality, compliance, safety가 중요한 domain에서는 pairwise preference만으로 부족하다.

1. Judge bias

LLM-as-a-judge에는 position bias, verbosity bias, style bias가 있다. 논문은 randomized evaluation을 여러 번 수행해 완화하지만, 완전히 제거되지는 않는다. Prompt가 실제로 더 좋은지, judge가 좋아하는 스타일로 바뀐 것인지를 구분해야 한다.

1. Sample overfitting

SPO는 적은 sample로 prompt를 빠르게 고친다. 이것이 장점이지만 동시에 약점이다. Appendix에서도 sample number와 iteration round가 커지거나 작아질 때 overfitting 또는 degradation 문제가 나타난다. Holdout test가 없으면 prompt가 3개 sample에만 맞춰질 수 있다.

1. Cross-model transfer 한계

논문은 현재 approach가 single model prompt optimization에 초점을 둔다고 명시한다. 한 모델에서 최적화된 prompt가 다른 model family에서도 잘 작동한다는 보장은 없다. 실제 서비스에서 model을 교체하거나 fallback model을 운영한다면, model별 prompt optimization이 필요할 수 있다.

1. Capability improvement와 output control의 구분

SPO는 prompt를 최적화할 뿐 model parameter를 바꾸지 않는다. 그래서 reasoning model의 근본적인 logical error나 knowledge gap을 해결하는 데는 한계가 있다. Repo의 추가 설명도 reasoning model에서는 core thought path 자체를 바꾸기보다 output structure와 requirement adherence를 다듬는 쪽에 더 가깝다고 해석한다.

1. Cost claim의 조건 의존성

0.15 USD per dataset이라는 수치는 사용한 model, API price, sample 수, iteration 수, prompt length에 따라 바뀐다. Long-context task나 expensive model을 evaluator로 쓰면 cost advantage가 줄어들 수 있다.

7. My Take

7-1. Why this matters for my work

내 관점에서 SPO는 prompt engineering을 조금 더 systematize하는 논문이다. 좋은 prompt를 사람이 감으로 고치는 대신, requirement, sample outputs, judge comparison을 이용해 반복적으로 개선한다. 이 구조는 LLM application 개발에서 꽤 바로 쓸 수 있다.

특히 다음 문제에 잘 맞는다.

• document QA 답변 format 개선
• OCR post-processing instruction refinement
• RAG answer style tuning
• agent tool-use instruction formatting
• report summarization template 개선
• customer support response policy alignment
• multilingual response tone adaptation

이런 task는 보통 gold label을 만들기 어렵다. 하지만 좋은 output과 덜 좋은 output을 비교하는 것은 상대적으로 쉽다. SPO는 이 차이를 잘 활용한다.

7-2. Reuse potential

실무에서 재사용한다면 나는 아래 구조로 쓸 것 같다.

1. Requirement spec을 먼저 만든다.

Prompt보다 먼저 evaluation rubric을 정한다. 예를 들어 factuality, format, coverage, conciseness, citation behavior, safety constraint를 항목화한다.

1. Small optimization set과 holdout set을 분리한다.

SPO loop에는 3개에서 5개 정도의 representative sample만 넣고, 최종 평가는 별도 20개에서 100개 holdout에서 수행한다. Label이 없어도 pairwise human audit이나 stronger judge를 사용할 수 있다.

1. Judge를 하나만 쓰지 않는다.

가능하면 evaluator를 2개 이상 두거나, judge prompt를 여러 variant로 둔다. A/B order shuffle도 필수다. 과도하게 verbose한 output을 선호하는 judge bias를 막기 위해 length-normalized rubric도 넣는 편이 좋다.

1. Prompt diff를 기록한다.

SPO는 prompt가 어떻게 바뀌는지 trajectory를 남긴다. 이 로그는 debugging에 중요하다. 어떤 iteration에서 format constraint가 강화됐는지, 어떤 iteration에서 reasoning instruction이 늘어났는지, 어떤 change가 실제 holdout에서 나빠졌는지 추적해야 한다.

1. Production auto-update에는 바로 쓰지 않는다.

SPO는 prompt candidate generator로는 유용하지만, production prompt를 자동 교체하는 agent로 쓰기에는 위험하다. Human approval 또는 offline evaluation gate를 두는 편이 맞다.

내가 보기엔 이 논문은 prompt optimizer 자체보다 evaluation design을 다시 생각하게 만든다. Prompt optimization의 병목은 prompt generation이 아니라 “prompt evaluation”이다. SPO는 이 evaluation bottleneck을 output pairwise comparison으로 줄인다. 이 관점은 prompt뿐 아니라 agent workflow optimization에도 확장 가능하다.

7-3. Follow-up papers

• Large Language Models are Human-Level Prompt Engineers, APE
  • LLM이 prompt 후보를 만들고 benchmark score로 선택하는 초기 자동 prompt engineering 계열이다.
• Large Language Models as Optimizers, OPRO
  • prompt optimization을 natural language optimization trajectory로 보는 대표 논문이다.
• TextGrad: Automatic Differentiation via Text
  • textual feedback을 gradient처럼 사용해 prompt나 solution을 개선하는 방향과 비교하기 좋다.
• PromptAgent
  • MCTS 기반 prompt search 관점에서 SPO의 low-cost greedy update와 대비된다.
• CRISPO
  • multi-aspect critique와 suggestion을 이용한 prompt optimization이라 SPO의 reference-free pairwise selection과 비교하기 좋다.

8. Summary

• SPO는 prompt optimization에서 external reference dependency를 줄이기 위한 reference-free framework다.
• 핵심은 output끼리 pairwise로 비교하고, 더 좋은 output을 만든 prompt를 다음 best prompt로 채택하는 것이다.
• Optimizer, executor, evaluator를 분리하고, 3 samples와 10 iterations로 low-cost prompt search를 수행한다.
• Closed task에서는 평균 성능과 cost-efficiency 조합이 좋고, open-ended task에서도 prompt interface 개선 효과를 보여준다.
• 다만 evaluator bias, sample overfitting, single-model optimization, capability improvement 한계는 반드시 함께 봐야 한다.