프롬프트 튜닝을 수작업에서 AI 튜닝으로: 유전 알고리즘 기반 자동 최적화와 고속화

3 hours ago 3

안녕하세요. LY Corporation의 Nakano입니다. Yahoo! JAPAN Search의 AI 응답 서비스에서 대규모 언어 모델(LLM) 최적화를 담당하고 있습니다.

이 글에서는 유전(genetic) 알고리즘을 사용해 프롬프트 튜닝을 자동화하고, 수일에서 수주가 걸리던 조정 작업을 약 한 시간으로 단축한 방법과 그 적용 사례를 소개합니다.

프롬프트 튜닝 시 마주치는 과제

LLM을 통합한 기능을 개발할 때 프롬프트 튜닝은 피할 수 없는 과정입니다. 이 작업에는 다음과 같은 문제가 있습니다.

시행착오를 반복해야 하는 부담: 프롬프트를 조금이라도 변경할 때마다 출력을 확인하고 의도한 대로 작동하는지 사람이 판단해야 합니다. 한 번의 시도로 수십에서 수백 가지의 패턴을 시험하는 경우도 드물지 않습니다.
각 개인에게만 머무르는 노하우: ‘이 표현을 넣으면 출력이 안정된다’, ‘이 순서로 지시하면 효과가 있다’ 등의 암묵적 지식이 담당자 개인에게 귀속되면서 시행착오 과정을 기록으로 남기기 어렵고, 왜 개선됐는지 설명하기도 어려워집니다.
느린 개선 사이클: 조정 → 출력 → 평가 사이클을 여러 번 반복해야 하므로, 조치 착수부터 완료까지 적게는 수일에서 많게는 수주까지 걸리는 경우가 있습니다.
모델 변경 및 업데이트를 추종하기 위한 비용 발생: 모델이 변경되거나 버전이 업데이트되면 출력 품질이 바뀔 수 있으며, 이에 따라 업데이트 주기가 빠른 생성 AI 모델을 사용할 때에는 지속적으로 재조정해야 합니다.

결과적으로 본래 사람이 집중해야 할 품질 판단이나 평가 관점 정리, 정책에 부합하는지 검증하는 작업에 리소스를 할애할 수 없게 됩니다.

이 문제를 해결하기 위해 프롬프트 튜닝 자체를 자동화하는 구조를 도입하는 도전을 시작했습니다.

프롬프트 자동 최적화 방법

여러 가지 최적화 방법

프롬프트 자동 최적화는 대규모 언어 모델이 부상한 이후 활발히 연구되고 있는 주제 중 하나로, 몇 가지 접근법이 존재합니다. 다음은 그 예입니다.

강화 학습 기반: 출력에 대한 스칼라 보상으로 정책 기울기(policy gradient)를 계산해 프롬프트 생성 정책을 학습하는 방법(GRPO 등).
베이지안(Bayesian) 최적화 기반: 후보 지시문과 퓨샷(few-shot) 예시를 탐색 공간으로 삼아 효율적으로 샘플링하는 방법(MIPROv2 등).
유전 알고리즘 기반: 후보 프롬프트를 집단으로 세대 교체하며 개선하는 방법(GEPA 등).

그중에서도 유전 알고리즘 기반 방법은 프롬프트가 자연어로 이산(discrete)적인 구조라는 점과 상성이 좋아 주목을 받고 있습니다. 실행 결과나 피드백을 자연어로 되돌아보며 문제점이나 개선 방안을 찾는 프로세스인 자연어 리플렉션(reflection)을 활용해 탐색적으로 개선을 진행할 수 있어 스칼라 보상에만 의존하는 강화 학습과는 접근법이 다릅니다. 이 글에서는 그 대표적인 방법인 GEPA를 소개하겠습니다.

GEPA의 최적화 루프

기본 아이디어는 ‘여러 후보 프롬프트를 생성하고 평가 점수가 높은 것을 남겨 개선을 반복한다’는 유전 알고리즘 및 진화적 계산 원리에 기반합니다. GEPA는 각 후보의 실행 결과를 자연어로 되돌아보는 리플렉션 기반 프롬프트 변이(Reflective Prompt Mutation)를 통해 문제를 특정한 뒤 개선안을 생성합니다. 또한 Pareto frontier 기반 선택을 통해 여러 평가 축을 고려해 균형 있게 우수한 후보를 유지합니다. 이 루프를 수 세대에서 수십 세대 반복하면 사람의 개입 없이 평가 기준에 맞는 출력을 내는 프롬프트로 수렴하며, 기존 최적화 기법보다 성능이 좋았다는 보고가 있습니다(ICLR 2026).

아래는 GEPA의 파이프라인 전체 모습입니다. 이 방법의 자세한 내용은 논문이나 다른 소개 글을 참조해 보세요!

DSPy와 GEPA를 이용한 구현

GEPA는 DSPy를 통해 사용할 수 있습니다. DSPy는 프롬프트 최적화를 코드로 제어할 수 있는 프레임워크이며, GEPA는 해당 프레임워크에서 자동하는 옵티마이저 중 하나로 공식 지원됩니다.

아래는 모듈 정의 개요입니다.

import dspy class TaskSignature(dspy.Signature): """당신은 유능한 어시스턴트입니다. 사용자 질문에 정중하게 답변해주세요.""" input = dspy.InputField(desc="입력 텍스트") output = dspy.OutputField(desc="생성 텍스트") class MyModule(dspy.Module): def __init__(self): super().__init__() self.predict = dspy.Predict(TaskSignature) def forward(self, input: str) -> dspy.Prediction: return self.predict(input=input)

시그니처의 독스트링(docstring) 부분이 LLM에 인스트럭션으로 전달되며, GEPA는 이를 재작성해 최적화합니다.

평가 함수 설계

GEPA에 전달하는 평가 함수는 단일 스칼라 값(float)을 반환해야 합니다. 평가 관점이 여러 개인 경우 각 관점의 점수를 집계하여 하나의 값으로 합칩니다.

GEPA가 높은 성능을 발휘하는 이유 중 하나는 스칼라 점수와는 별개로 자연어 형태의 피드백을 리플렉션 프로세스로 전달할 수 있다는 점입니다. 평가 함수에서 dspy.Prediction(score=..., feedback=...)를 반환하면 ‘어떤 관점에서 문제가 있는지’, ‘왜 감점되었는지’ 등을 GEPA의 리플렉션 기반 프롬프트 변이 과정(Reflective Prompt Mutation)으로 전달할 수 있습니다. 점수만으로는 ‘0.6이었다’ 정도만 알 수 있지만, 피드백을 통해서는 ‘관점 B에 문제가 있어 감점되었다’처럼 구체적으로 전달할 수 있기 때문에 적절한 개선 방향을 찾을 것이라고 기대할 수 있습니다.

또한, 평가 함수의 첫 번째 인수인 gold에는 학습 데이터의 각 샘플이 전달됩니다. 정답 데이터(기대 출력이나 레이블)를 준비할 수 있는 작업이라면 gold를 참조하여 정답과의 비교에 기반한 평가도 가능합니다. 아래 예제 코드에서는 gold를 사용하지 않는 형태로 LLM-as-a-Judge에 기반한 자동 평가를 정의하고 있으나, 규칙 기반으로 맞는지 틀리는지 판정하는 등의 방법으로 점수를 매기는 것도 가능합니다.

def create_metric(eval_lm: dspy.LM): """다중 관점 평가 메트릭""" class QualityEval(dspy.Signature): output = dspy.InputField(desc="평가 대상 생성 텍스트") criteria = dspy.InputField(desc="평가 기준") criterion_a = dspy.OutputField(desc="관점 A의 점수", format=int) criterion_b = dspy.OutputField(desc="관점 B의 점수", format=int) criterion_c = dspy.OutputField(desc="관점 C의 점수", format=int) explanation = dspy.OutputField(desc="평가 이유") evaluator = dspy.ChainOfThought(QualityEval) def metric_fn(gold, pred, trace=None, pred_name=None, pred_trace=None): criteria = "..." # 각 관점의 상세한 평가 기준을 기술 with dspy.context(lm=eval_lm): out = evaluator(output=pred.output, criteria=criteria) # 각 관점을 0-10으로 채점하고, 합계를 정규화하여 단일 스칼라 값으로 집계 scores = [ max(0, min(10, int(out.criterion_a))), max(0, min(10, int(out.criterion_b))), max(0, min(10, int(out.criterion_c))), ] score = sum(scores) / (10 * len(scores)) # 평가 이유를 feedback으로 GEPA의 리플렉션에 전달 return dspy.Prediction(score=score, feedback=out.explanation) return metric_fn

최적화는 다음과 같이 실행합니다. 추론, 평가, 리플렉션용 모델을 각각 별도로 설정할 수 있습니다.

# 추론용 모델(최적화 대상 모듈이 사용하는 LLM) task_lm = dspy.LM("openai/gpt-4o-mini") # 평가용 모델(LLM-as-a-Judge가 사용하는 LLM) eval_lm = dspy.LM("openai/gpt-4o") # 리플렉션용 모델(GEPA가 개선안을 생성할 때 사용하는 LLM) reflection_lm = dspy.LM("openai/gpt-4o") dspy.configure(lm=task_lm) metric = create_metric(eval_lm=eval_lm) optimizer = dspy.GEPA( metric=metric, reflection_lm=reflection_lm, num_candidates=10, num_generations=15, ) optimized_module = optimizer.compile( MyModule(), trainset=training_examples, )

수행 과제 소개

Yahoo! JAPAN Search AI 응답 중 건강·의료 관련 쿼리

Yahoo! JAPAN Search의 AI 응답 서비스에서는 사용자의 검색 쿼리에 대한 답변을 LLM이 직접 생성합니다. 다양한 카테고리에 대해 답변 품질을 높이기 위해 개선하고 있는데요. 그중에서도 건강·의료 관련 쿼리는 일반 쿼리와 비교해 준수해야 할 정책이 많은 것이 특징입니다. 예를 들어 ‘단정적인 의료 판단을 하지 않을 것’, ‘근거 수준에 맞는 표현을 사용할 것’, "진료 권유를 적절히 포함할 것" 등 답변에 요구되는 조건이 다양합니다.

두 가지 개선 목표

이 과제에서는 다음 두 가지를 동시에 달성할 필요가 있었습니다.

요건 준수: 건강·의료 쿼리 고유의 여러 정책을 만족하는 답변을 생성한다.
가독성 개선: 일반 쿼리에서 도입된 마크다운 형식(제목, 목록, 강조 등)을 건강·의료 쿼리에도 적용하여 사용자가 읽기 쉬운 답변으로 만든다.

요건 준수와 가독성 개선은 모두 프롬프트 지시로 제어해야 하지만, 정책이 많을수록 프롬프트 조정이 복잡해져 한쪽을 개선하면 다른 쪽이 무너지는 문제가 발생하기 쉽습니다. 이를 사람이 동시에 최적화하기에는 작업량이 너무 많기 때문에 자동 최적화를 적용해 봤습니다.

수행 과제에 프롬프트 최적화 적용

앞서 소개한 범용 구조를 수행 과제에 적용한 방법을 살펴보겠습니다.

실험 설정

시그니처는 사용자의 검색 쿼리를 입력받아 AI 답변을 출력하는 단순한 구성입니다. 초기 프롬프트에는 이미 조정된 범용 프롬프트에 건강·의료 고유의 정책 문구를 단순히 이어붙인 문장을 설정해 두었으며, GEPA는 이 인스트럭션 부분을 재작성하여 최적화합니다.

아래는 초기 프롬프트 구성의 이미지(일부 발췌·변경)입니다.

검색 쿼리에 대해 다음 요구 사항을 엄격히 준수하여 마크다운 형식으로 답변을 생성해 주세요. ## 답변 품질 요구 사항 - 구체성: 쿼리에 대한 구체적이고 실용적인 답변을 우선 제시할 것 - 의도 해석: 쿼리의 의도를 정확히 파악하고, 필요한 정보를 과부족 없이 포함할 것 (...중략: 답변 구조, 형식, 체크리스트, 답변 예시...) ## 반드시 지켜야 할 조건 - 항상 정확하고 성실한 정보를 제공하며, 허구의 정보나 확증 없는 정보는 제공하지 않습니다. (...중략...) ### 건강·의료 주석 가이드라인 준수 규칙(MUST) #### 1) 답변 범위 - 일반적 설명만 (정의·증상·원인·경과·예방·합병증). #### 2) 공통 규칙(금지·제약) - [진단 행위] 질병명/중증도의 단정 금지. - [단정 표현] "효과적이다"/"필요하다"/"최적" 등 단정적 표현 금지. (...이하, 좋지 않은 어간 정규표현식 리스트 등 계속...)

위와 같이 범용적인 답변 규칙 말미에 건강·의료 고유의 가이드라인을 추가한 구조입니다.

GEPA 실행 설정은 다음과 같습니다.

optimizer = dspy.GEPA( metric=metric_fn, auto="light", num_threads=8, track_stats=True, reflection_minibatch_size=3, reflection_lm=eval_lm, )

auto="light"는 최적화의 계산 예산을 제어하는 파라미터로 "light" / "medium" / "heavy" 중에서 선택할 수 있습니다. 이번에는 "light"를 지정하여 짧은 시간 내에 비용 대비 성능이 좋은 결과를 얻도록 설정했습니다. reflection_minibatch_size=3으로 설정하면 리플렉션 프로세스 시 3샘플씩 미니 배치로 처리해 효율적으로 개선안을 생성합니다.

평가 함수 정의

건강·의료 관련 쿼리가 충족해야 할 정책을 네 가지 관점(진단 행위, 단정 표현, 특정 고유명사 추천, 심리적 부담)으로 나누어 정의했습니다. 정의한 정책을 각각 0~10점으로 평가하는 LLM-as-a-Judge를 구축하고, 네 관점의 점수 평균을 구해 단일 스칼라 값으로 집계합니다. 가독성 개선에 관한 정책에도 동일한 평가 체계를 적용했습니다.

아래는 특정 쿼리에 대한 출력을 평가한 결과 예시입니다(점수와 피드백은 실제 값과 다를 수 있습니다).

관점점수피드백 예시

진단 행위	8/10	질병명을 단정하지는 않지만 "~일 가능성이 높다"라는 표현이 1곳 남아 있습니다.
단정 표현	6/10	"효과적입니다", "필요합니다" 등의 금지어가 3곳에서 사용되었습니다.
고유명사 추천	10/10	특정 상품명·약제명 추천 없음
심리적 부담	9/10	전반적으로 무난한 표현이나 "방치하면 위험하다"는 문구가 다소 불안을 조성합니다.

이 예에서는 총점이 (8+6+10+9) / 40 = 0.825가 되어, 각 관점의 문제점이 피드백으로 GEPA의 리플렉션 프로세스에 전달됩니다. GEPA는 이 피드백을 바탕으로 '단정 표현 제거'에 중점을 둔 개선안을 생성할 수 있습니다.

운영 설계

자동 최적화 구조를 실제 서비스에 적용할 때 어디까지 자동화하고 어디서 사람이 최종 판단을 내릴지 경계를 설계하는 것이 중요합니다. 본 과제에서는 재현 가능한 판단은 자동화하고 문맥에 의존해야 하는 판단은 사람에게 남기는 방침을 기준으로 다음과 같이 역할을 분담했습니다. 이렇게 분담하면 사람은 프롬프트 미세 조정 후 확인 반복 같은 루틴 작업에서 해방되어 본래 집중해야 할 품질 판단과 정책 설계에 전념할 수 있게 됩니다.

자동화 범위
- 후보 프롬프트의 생성·개선(GEPA 진화적 탐색)
- 각 후보의 실행 및 출력 획득
- LLM-as-a-Judge에 따른 정책 준수 점수 산출
- 점수에 기반한 후보의 선택·도태
사람이 판단하는 범위
평가 관점(정책)의 정의 및 우선순위 지정
최적화 결과를 정성적으로 평가
평가 누락 발견 및 평가 프롬프트에 대한 피드백
운영 환경으로 최종 릴리스할지 판단

최적화 프로세스 설계

먼저 가독성 정책(마크다운 정형화)의 평가 함수로 최적화를 실행해 구조화된 답변을 생성할 수 있는 프롬프트를 확보합니다. 그 후 건강·의료 정책의 평가 함수로 다시 최적화를 수행해 가독성을 유지하면서 요건 준수를 달성하는 프롬프트로 완성했습니다.

구체적으로는 다음 단계를 밟았습니다.

가독성 정책으로 최적화 실행
사람 검토: 최적화 결과를 사람이 확인해 자동 평가가 놓친 문제 찾아내기
평가 수정: 발견된 평가 누락을 평가 프롬프트에 반영
건강·의료 정책으로 최적화 실행
다시 사람 검토: 앞서와 동일하게 사람이 확인해 평가 누락 찾아내기
평가 수정: 평가 프롬프트 다시 개선

이와 같이 ‘자동 최적화 → 사람 검토 → 평가 수정’ 사이클을 반복하는 방법으로 자동 평가의 정밀도 자체도 단계적으로 향상될 것으로 기대합니다.

프롬프트 최적화 적용 결과

본 기법을 적용한 결과 다음과 같은 성과를 얻었습니다.

최적화 시간: 기존 수동 튜닝으로 수일에서 수주 걸리던 작업을 약 한 시간에 완료
요건 준수율: 사람의 정성적 평가에서 거의 100%의 정책 준수를 달성해 릴리스 기준 충족
공수 절감: 프롬프트 시행착오에 소요되던 시간을 줄여 평가 설계나 정책 정비 등 고차원적 판단 업무에 더 많은 시간을 할애할 수 있게 됨

아래는 쿼리 ‘수막염 두통 특징’에 대한 응답을 최적화 전후로 비교한 결과입니다. Before가 최적화 전, After가 최적화 후입니다. 최적화 전에는 목록과 굵은 글씨만으로 정보가 나열돼 있었지만 최적화 후에는 ‘수막염 두통의 주요 특징’, ‘기타 증상’ ‘원인과 종류’, ‘진단과 치료’와 같은 제목으로 정보가 정리돼, 읽기 쉽게 구조화된 응답이 되었습니다. 참고로 아래 이미지 속 화면은 아직 개발 중으로 실제 검색 결과에 표시되는 문장과는 다를 수 있습니다. 또한 해당 서비스는 일본에서 일본어로만 제공되고 있으며, 한국어 내용은 독자의 이해를 돕기 위해 AI를 이용해 번역해 추가해 놓은 것입니다.

최적화 전후 비교

프롬프트 자체도 크게 재구조화되었습니다. 아래는 최적화 후 프롬프트 구성의 일부를 가져온 것입니다(발췌 및 수정한 내용입니다).

## 1. 예상 작업·전제 - 답변 대상은 의학·영양 전문 지식이 없는 일반 사용자입니다. - 답변은 '검색 결과 요약'처럼 간결하고 실용적으로 정리해 주세요. ## 2. 답변의 전체 구조·분량 ### 2-1. 3층 구조(필수) 1. 서두의 직접 응답(1단락) 2. 상세 설명 3. 보충·주의 사항 ## 4. 내용 측면의 가이드라인 ### 4-3. 병명·증상 계열 쿼리 - 기본 구성: 1. 개요 2. 주요 증상 3. 원인·요인 4. 검사·치료 선택지 5. 예방·생활상 주의 ## 5. 건강·의료 가이드라인(필수) ### 5-2. 금지 사항·제약 표현 1. 진단 행위 금지 2. 단정적 표현 금지 - "유효하다" → "효과가 기대된다" - "~가 원인입니다" → "~가 관여할 수 있습니다" (... 이하, 바꿔쓰기 템플릿, 면책 문구, 최종 체크리스트 ...)

최적화 전에는 범용 규칙의 말미에 건강·의료 가이드라인을 덧붙인 수준의 구조였으나, GEPA가 7장 구성으로 재편해 쿼리 유형별 가이드라인과 바꿔쓰기 템플릿을 체계적으로 통합했습니다.

아래는 건강·의료 정책에 관한 자동 평가 점수의 추이입니다. 세대를 거듭할수록 점수가 향상돼 100점에 도달하는 후보가 늘어납니다.

건강 의료 정책의 평가 점수 추이

한편, LLM-as-a-Judge의 자동 평가는 판정 일관성에 문제가 있는 것으로 알려져 있습니다. Gu 등이 작성한 서베이 논문 A Survey on LLM-as-a-Judge에 따르면 LLM 평가기가 동일한 입력에 대해서도 일관되지 않은 점수를 낼 수 있으며, 문맥의 미묘한 변화가 동일한 입력에 대한 판정을 바꿀 수 있다고 보고했습니다. 또한 고급 추론 능력을 가진 모델이라도 인간의 평가와 완전히 일치하지는 않아 LLM에는 개선할 여지가 있다고 지적합니다. 이러한 불일치를 줄이기 위한 접근 방식으로는 동일 평가를 여러 번 실행해 다수결로 결정하는 방법이나, 이 글에서 소개한 최적화 프로세스처럼 인간의 피드백을 평가 프롬프트에 반영하는 반복적 최적화 기법이 제안되고 있습니다.

이 과제에서도 이러한 특성을 확인했습니다. 최적화 전 출력에 포함된 ‘수막염으로 인한 두통은 발열, 구토, 경련, 의식장애와 같은 다른 증상과 거의 반드시 동시에 나타난다’라는 표현은 LLM-as-a-Judge가 ‘진단 행위에 해당한다’고 판정했는데요. 최적화 후 출력에 유사한 문구가 포함되어 있음에도 진단 행위로 판정되지는 않았습니다. 실제로 증상의 일반적 설명은 정책상 진단 행위에 해당하지 않으므로 사람 검토에서도 문제없다고 판단해 릴리스했습니다.

이 방법의 몇 가지 제약 사항

GEPA는 수작업 튜닝을 줄이는 강력한 방법이지만, 실제로 적용해 보면서 몇 가지 제약을 느끼기도 했습니다.

단일 스칼라 값을 반환하는 평가 함수

이번에 수행한 건강·의료 계열 쿼리 개선처럼 여러 평가 축의 점수를 평균내면 개별 축의 평가 결과가 묻힐 수 있습니다. 휴리스틱(heuristic)하게 가중치를 부여해 점수 표현력을 높이는 방법도 생각할 수 있지만, 그렇게 하면 프롬프트 튜닝을 자동화했음에도 이번에는 가중치의 하이퍼파라미터 튜닝이라는 새로운 과제가 발생할 가능성이 있습니다.

병목이 될 수 있는 사람 평가

튜닝 자체는 약 한 시간 수준으로 단축됐지만 자동 최적화 전후에 사람이 검토할 필요가 있으므로 그 부분이 병목이 될 수 있습니다. 다만 사람의 피드백을 평가 프롬프트에 반영하면 다음 최적화에 직접 활용할 수 있다는 장점도 있습니다.

프롬프트 비대화

GEPA가 생성한 최적화 프롬프트에는 평가 결과에서 얻은 개별 사례가 퓨샷 형태로 많이 삽입되는 경향이 있습니다. 이번 수행 과제에서는 최적화하면서 프롬프트가 5,521자에서 8,561자로 약 55% 증가했습니다. 따라서 추론 비용과 지연 시간에 미치는 영향을 고려할 필요가 있습니다. 예를 들어 최적화 후 프롬프트에는 다음과 같은 쿼리 유형별 구체적 구성 예시가 추가되어 있습니다(발췌 및 수정한 내용입니다).

### 4-3. 질병·증상 계열 쿼리 - 기본 구성: 1. 개요 2. 주요 증상 - 예: "허혈성 장염" - 갑작스러운 복통(특히 왼쪽 하복부) - 복통에 이어지는 설사 - 선혈을 포함한 혈변 - 예: "마이코플라즈마 폐렴 성인 증상" - 오래 지속되는 마른 기침 - 38°C 이상의 발열 또는 간헐적 발열 - 권태감(피로), 두통 3. 원인·요인 4. 검사·치료의 선택지 5. 예방·생활상 주의

이와 같이 개별 사례를 삽입하는 것이 프롬프트 비대화의 주요 원인입니다.

차분 정보를 활용하지 않음

현 방법에서는 각 세대의 후보 프롬프트를 개별적으로 평가하며, 이전 세대와의 차분, 즉 프롬프트 변경점과 출력 변화의 대응 관계를 명시적으로 활용하지 않습니다. 언어처리학회 제32회 연례대회(NLP2026)에서 발표된 연구에서는 직전과 현재의 프롬프트, 추론 결과의 차이를 분석해 개선점을 자연어로 특정하고 수정하는 방법을 제안했으며, GEPA를 상회하는 정밀도가 보고되었습니다(古賀ら, 2026(일본어)).

향후 전망: 개선 루프 공통 기반화 및 사람 개입 없는 프로덕트 개선

개선 루프의 기반화

현재는 정책별로 ‘평가 설계 → 최적화 실행 → 사람 검증 → 반영’의 사이클을 개별적으로 운영하고 있습니다. 앞으로는 이 개선 루프 자체를 공통 기반으로 정비해 건강·의료에 국한하지 않고 검색, 광고, 커머스, 사내 업무 등 정책 준수가 요구되는 LLM 기능 전반에 걸쳐 확산해 나가는 것을 목표로 하고 있습니다.

AI가 자율적으로 프로덕트 개선

한층 더 나아간 전망으로는, 사람의 개입 없이도 자율적으로 개선이 계속 반복 실행되는 체계를 지향합니다.

운영 환경을 모니터링하며 품질 저하를 감지하고 자동으로 최적화를 실행한다.
새로운 정책이 추가되면 평가 프롬프트 생성부터 최적화 실행까지 자동으로 수행한다.
최적화 결과의 검증·승인 절차만 사람이 담당하고, 개선 실행 자체는 AI가 자율적으로 수행한다.

단발성 정책 개선에 그치지 않고 제품이 스스로 품질을 유지하고 향상시키는 기반을 구축하는 것이 저희 서비스의 목표가 될 것이라고 생각합니다.

마치며

이번 글에서는 DSPy와 GEPA를 활용한 프롬프트 자동 최적화 기법과 Yahoo! JAPAN Search의 AI 응답 중 건강·의료 계열 쿼리에 적용한 사례를 소개했습니다.

프롬프트 튜닝을 자동화하면 조정 작업의 공수를 크게 줄일 수 있을 뿐 아니라, 사람이 본래 집중해야 할 평가 설계나 정책 정비에 더 많은 시간을 할애할 수 있습니다. 프롬프트 튜닝에 어려움을 느끼거나 LLM을 통합한 기능·서비스의 품질 개선을 효율화하려는 분들에게 이 글이 도움이 되길 바랍니다. 자신의 작업에 맞는 평가 함수를 설계하고 자동 최적화하는 것을 꼭 시도해 보시기 바랍니다!