OPRO 자동 프롬프트 최적화 기법이 소형 LLM에서 실패하는 이유를 시각화한 복잡한 데이터 처리 다이어그램. 빛나는 클라우드와 연결된 기술적 요소들이 LLaMa 같은 소형 LLM의 OPRO 실패 원인을 상징
|

자동 프롬프트 최적화, OPRO가 소형 LLM에서 실패하는 이유

OPRO: ‘자동 프롬프트 최적화’, 소형 LLM에서는 왜 작동하지 않을까?

LLM의 성능은 프롬프트에 달려있습니다. “Let’s think step by step” (CoT) 같은 ‘마법의 주문’이 LLM의 추론 능력을 극적으로 끌어올린다는 것은 잘 알려진 사실이죠.

초기에는 우리 같은 개발자나 기획자가 직접 최적의 프롬프트를 만들었습니다. 하지만 최근에는 이 과정마저 자동화하려는 시도(APE, APO 등)가 많았습니다. 그 정점에 있는 기술이 바로 OPRO (Optimization by PROmpting)입니다.

OPRO의 개념은 흥미롭습니다. LLM에게 “네가 직접 이 문제를 가장 잘 풀 수 있는 ‘최고의 프롬프트’를 찾아봐”라고 시키는 것, 즉 LLM 자체를 ‘옵티마이저(optimizer)’로 활용하는 방식입니다. GPT-4 같은 초거대 모델에서는 이 방법이 SOTA(최고 성능)를 달성하며 큰 주목을 받았습니다.

하지만 우리에겐 현실적인 질문이 남습니다. 우리 모두가 GPT-4만 사용하는 것은 아니니까요. LLaMa-2나 Mistral 7B처럼 로컬에서도 실행 가능한 ‘소형 LLM(sLLM)’에서는 어떨까요?

최근 USC의 한 연구가 이 질문에 대한 답을 내놓았습니다.

결론부터 말씀드리면, ‘아니오’에 가깝습니다.

연구진은 OPRO가 소형 LLM에서는 효과가 매우 제한적이며, 이는 모델의 “제한된 추론 능력”이 “최적화 능력”의 발목을 잡기 때문이라고 분석했습니다.

이건 ‘성능이 조금 낮다’ 정도의 문제가 아닙니다. OPRO를 적용하느라 비싼 컴퓨팅 자원만 낭비하고, 정작 결과는 가장 단순한 “Let’s think step by step” (Zero-shot CoT)보다 못할 수도 있다는 뜻입니다.

이 글에서는 해당 연구를 바탕으로 OPRO가 왜 소형 LLM에서 실패하는지, 그리고 우리는 어떤 현실적인 전략을 취해야 하는지 명쾌하게 정리해 보겠습니다.

1단계: 첫 번째 균열 (기본 수학 문제 실패)

연구진은 먼저 간단한 ‘선형 회귀 최적화’ 문제(특정 손실 함수를 최소화하는 w와 b 값을 찾는 수학 문제)를 LLaMa-2-13B 모델로 테스트했습니다.

OPRO의 메타 프롬프트는 모델에게 기존 (w, b) 값과 그때의 손실 값을 보여주며, 이보다 더 나은(손실이 낮은) 새로운 (w, b) 쌍을 제안하라고 요청합니다.

대형 모델이라면 이 기록을 보고 더 나은 값을 추론해내야 합니다. 하지만 LLaMa-2-13B는 최적화는커녕, 다음과 같이 혼란스러운 답변을 내놓았습니다.

“저는 그래디언트 디센트 알고리즘을 사용해 보았지만, 예상대로 작동하지 않습니다. … 잘 모르겠습니다. 더 나은 (w, b) 쌍을 찾는 것을 도와주세요.”

모델이 최적화 작업을 수행하다 실패했다는 ‘자기 보고’를 한 셈입니다. 이는 소형 LLM이 기본적인 수학 문제조차 최적화할 능력이 부족하며, OPRO 기법이 작동하지 않을 것이라는 첫 번째 경고 신호였습니다.

2단계: 본 게임 (OPRO vs. CoT, 처참한 패배)

연구진은 이어서 초등학교 수학 문제(GSM8K) 벤치마크로 본게임을 진행했습니다. LLaMa 계열, Mistral 7B 같은 소형 LLM과 Gemini-Pro(대형 LLM)를 대상으로 세 가지 기법을 비교했습니다.

  • Zero-shot-CoT: “Let’s think step by step”
  • Few-shot-CoT: 2개의 풀이 예시 제공
  • OPRO: LLM이 스스로 최적의 지시어를 탐색

결과는 충격적이었습니다.

Gemini-Pro (대형 모델):

예상대로 OPRO가 76.92%의 정확도로 CoT 기법들(71.29%, 69.67%)을 크게 앞섰습니다. OPRO가 대형 모델에게는 효과적임이 재확인되었습니다.

하지만 소형 LLM은 정반대였습니다.

Mistral 7B:

  • OPRO: 32.13%
  • Zero-shot-CoT: 37.52% (OPRO 패)
  • Few-shot-CoT: 38.13% (OPRO 패)

LLaMa-2-13B:

  • OPRO: 31.24%
  • Zero-shot-CoT: 32.75% (OPRO 패)
  • Few-shot-CoT: 37.15% (OPRO 패)

LLaMa-2-70B (가장 큰 소형 모델):

  • OPRO: 27.98%
  • Zero-shot-CoT: 39.35% (OPRO 대패)
  • Few-shot-CoT: 48.67% (OPRO 대패)

결론은 명백합니다. 모든 소형 LLM에서 OPRO가 가장 낮은 점수를 기록했습니다. 특히 LLaMa-70B의 경우, OPRO를 썼더니 예시 2개를 준 것(Few-shot)보다 성능이 20%p 가까이 추락했습니다.

이는 소형 LLM이 OPRO를 통해 스스로를 최적화하기는커녕, 가장 단순한 “Let’s think step by step”조차 이기지 못했다는 의미입니다. 소형 LLM에게는 OPRO의 ‘자율성’보다 ‘명확한 지시'(Few-shot-CoT)가 훨씬 효과적이었습니다.

3단계: 심층 분석 (왜 OPRO는 실패했는가?)

연구진은 이 실패의 원인을 몇 가지로 나누어 분석했습니다.

원인 1: 제한된 추론 능력 (핵심 원인)

가장 근본적인 원인입니다. OPRO는 LLM이 피드백을 이해하고 더 나은 전략(지시어)을 생성하는 ‘자체 최적화’ 능력에 기반합니다.

이는 마치 학생에게 ‘문제를 풀라’고 하는 대신 ‘더 좋은 시험 문제를 만들어보라’고 시키는 것과 같습니다. 대형 모델은 똑똑해서 훌륭한 시험 문제를 만들 수 있지만, 소형 모델은 그럴 만한 추론 능력이 부족합니다.

OPRO가 찾아낸 ‘최적의 지시어’를 비교하면 이 차이가 극명합니다.

(나쁜 사례) LLaMa-2-13B가 찾은 지시어:

“Let’s think about”

(기존 CoT 프롬프트의 모방일 뿐, 최적의 해결책을 찾지 못함)

(좋은 사례) Gemini-Pro가 찾은 지시어:

“To attain the utmost precision in solving diverse grade school mathematical problems, meticulously adhere to this comprehensive and rigorously developed methodology:”

(작업의 본질(“grade school mathematical problems”)을 정확히 이해하고 최적화된 지시어를 생성함)

원인 2: 형편없는 ‘스코어러(Scorer)’

OPRO는 LLM이 ‘옵티마이저'(새 프롬프트 생성)와 ‘스코어러'(프롬프트 평가) 역할을 모두 해야 합니다. 하지만 소형 LLM은 이 ‘스코어러’ 역할에 실패했습니다.

앞선 비유를 다시 사용하자면, ‘좋은 시험 문제’를 만들지도 못하지만, ‘어떤 문제가 좋은 문제인지’ 채점하지도 못하는 겁니다.

연구진이 흥미로운 추가 실험을 했습니다.

  • 옵티마이저(LLaMa) / 스코어러(LLaMa) → 성능 불안정
  • 옵티마이저(LLaMa) / 스코어러(Gemini-Pro) → 정확도 5% 향상

즉, LLaMa가 더 나은 프롬프트를 만들 잠재력이 아예 없는 것은 아니지만, 스스로 무엇이 ‘좋은 프롬프트’인지 판단할 ‘눈’이 없는 것입니다.

원인 3: ‘자동화’의 배신 (여전한 수동 의존성)

OPRO의 목표는 ‘자동화’입니다. 하지만 연구 결과, 소형 LLM은 OPRO를 실행하기 위해 인간이 처음에 설계해 주는 ‘메타 프롬프트’에 따라 성능이 엄청나게 요동쳤습니다.

LLaMa-2-13B의 경우, 가장 좋은 메타 프롬프트(31.24%)와 가장 나쁜 메타 프롬프트(10.39%)의 성능 차이가 3배에 달했습니다. 이는 ‘자동화’라고 부르기 무색하게, 그 성패가 여전히 인간의 ‘수동 프롬팅’에 달려있다는 것을 의미합니다.

원인 4: 엄청난 비효율성 (비용과 시간)

마지막으로 비용입니다. OPRO는 매 이터레이션마다 스코어러가 프롬프트를 평가하는 과정을 거치기 때문에 토큰 사용량이 매우 높습니다.

Gemini-Pro 기준으로도 OPRO는 CoT 방식보다 4~5배 더 많은 시간을 소요하며 막대한 양의 토큰을 소비했습니다. 대형 모델에서 얻는 약간의 성능 향상조차 이 엄청난 비용을 정당화하기 어려울 수 있는데, 성능이 오히려 떨어지는 소형 모델에서는 말할 것도 없습니다.

4단계: 결론 및 개발자 가이드

이번 연구는 OPRO 같은 ‘자체 최적화’ 기법이 소형 LLM의 제한된 추론 능력 때문에 효과적이지 않다는 것을 실증적으로 보여주었습니다.

그렇다면 LLaMa나 Mistral 7B 같은 소형 LLM을 활용하는 개발자와 연구자는 어떻게 해야 할까요? 이 논문은 명확한 가이드를 제시합니다.

“소형 LLM의 경우, 목표와 방법론을 명확하게 설명하는 ‘직접적인 지시(direct instructions)’를 강력한 프롬프트 베이스라인으로 권장합니다.”

즉, OPRO처럼 복잡하고 비용이 많이 드는 자동화 기법에 의존하기보다, “Let’s think step by step” 같은 전통적인 CoT 프롬프트나, 잘 구성된 몇 개의 예시(Few-shot)를 제공하는 것이 훨씬 더 효율적이고 효과적인 전략입니다.

모든 모델에 맞는 ‘만병통치약’ 기법은 없습니다. 우리가 사용하는 모델의 규모와 능력에 맞는 최적의 접근 방식을 선택하는 것이 중요합니다.

프롬프트 엔지니어링으로 AI를 마스터하세요

ProB AI 연구소에서는 계속해서 AI와 프롬프트 엔지니어링의 최신 기법과 전략을 연구하고 있습니다. 더 많은 인사이트를 얻고 싶으신가요?

ProB AI 연구소 방문하기

Similar Posts