사람이 문구를 하나씩 고치는 대신 입출력 예시와 채점 기준을 주면, 시스템이 여러 프롬프트 후보를 만들어 시험하고 점수가 가장 높은 것을 골라 주는 방식이다. 분류·추출처럼 정답을 판단할 기준이 있는 반복 작업에 쓰고, 모델을 바꿔도 다시 돌리기만 하면 된다는 점이 수동 조율과 다르다.
| 항목 | 수동 조율 | 자동 최적화 |
|---|---|---|
| 누가 고치나 | 사람이 감으로 | 시스템이 후보를 만들어 비교 |
| 판단 근거 | 예시 몇 개를 눈으로 확인 | 데이터셋 점수 |
| 모델을 바꾸면 | 처음부터 다시 조율 | 다시 돌리면 끝 |
| 드는 것 | 사람의 시간 | 데이터와 API 호출 비용 |
원리는 단순하다. LLM이 현재 프롬프트를 바꾼 후보를 여러 개 만들고, 각 후보로 예시 데이터를 풀게 한 뒤 점수를 매긴다. 점수가 좋은 후보를 바탕으로 다시 변형을 만들며 몇 차례 반복한다.
무엇을 바꾸는지는 도구마다 다르다. 지시문을 고치기도 하고, 프롬프트에 넣을 퓨샷 예시를 고르기도 하며, 틀린 답에 대한 피드백을 글로 받아 프롬프트를 고치기도 한다.
| 도구 | 주로 바꾸는 것 | 쓰는 곳 |
|---|---|---|
| DSPy 옵티마이저 | 지시문, 퓨샷 예시 | 파이썬 코드 |
| TextGrad | 글로 된 피드백을 반영해 수정 | 파이썬 코드 |
| Anthropic 프롬프트 개선 기능 | 지금 쓰는 프롬프트 다듬기 | 콘솔 화면 |
DSPy에서는 작업을 프로그램으로 정의하고, 정답 데이터셋과 채점 함수를 준비해 옵티마이저에 넘긴다. BootstrapFewShot을 쓰면 compiled_program = teleprompter.compile(program, trainset=train_data) 한 줄로 최적화된 프롬프트와 퓨샷 예시가 만들어진다.
순서는 정답 예시 준비 → 채점 함수 작성 → 컴파일 → 따로 떼어 둔 검증 데이터로 확인이다. 모델을 바꾸거나 도메인이 바뀌면 프롬프트를 손으로 고치지 말고 다시 컴파일하면 된다.
| 상황 | 추천 | 이유 |
|---|---|---|
| 분류·추출처럼 정답이 분명한 반복 작업 | 쓴다 | 점수로 비교하기 쉽다 |
| 여러 단계로 이어진 LLM 파이프라인 | 쓴다 | 단계별 프롬프트를 한꺼번에 맞춘다 |
| 한 번 쓰고 마는 질문 | 안 쓴다 | 준비하는 수고가 더 크다 |
| 좋은 답의 기준이 모호한 글쓰기 | 신중히 | 채점이 흔들리면 결과도 흔들린다 |
최적화는 주어진 데이터에서 점수를 올리는 데만 집중한다. 그래서 예시가 적거나 한쪽에 치우치면 실제 입력에서는 오히려 나빠질 수 있다. 학습용과 검증용 데이터를 나누고, 만들어진 프롬프트를 사람이 한 번 읽어 보는 게 안전하다.
후보마다 데이터셋 전체를 돌리기 때문에 API 호출이 많이 쌓인다. 처음에는 작은 데이터와 저렴한 모델로 돌려 보고, 효과가 확인되면 범위를 넓히는 편이 좋다.
가장 흔한 쓰임은 계속 돌아가는 LLM 작업의 프롬프트를 정답 예시로 맞추는 것이다. 한 번 맞춰 두면 모델이나 데이터가 바뀔 때마다 다시 돌려 프롬프트를 갱신한다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 분류·추출 자동화 | 라벨이 달린 예시 수십~수백 개와 정확도 채점 함수로 지시문과 퓨샷 예시를 고른다 |
| 여러 단계 LLM 파이프라인 | 검색 → 요약 → 답변처럼 이어진 단계를 DSPy 프로그램으로 묶고 최종 답 점수로 한꺼번에 컴파일한다 |
| 모델 교체 | 더 싸거나 새로운 모델로 옮길 때 손으로 다시 조율하지 않고 같은 데이터로 재최적화한다 |
| 콘솔에서 프롬프트 다듬기 | 지금 쓰는 프롬프트를 개선 기능에 넣어 초안을 받고, 예시 몇 개로 결과를 확인한다 |