LLM 정확도 최적화

LLM의 응답 정확도와 동작 일관성을 최대한 높이는 방법

LLM 최적화는 쉽지 않습니다.

스타트업부터 대기업까지 여러 개발자와 협업하면서, 최적화가 어려운 이유를 다음 세 가지 질문으로 정리할 수 있었습니다.

• 정확도를 높이려면 어디서부터 시작해야 할까?
• 언제 어떤 최적화 방법을 써야 할까?
• 프로덕션에 적용하려면 정확도가 어느 정도면 충분할까?

이 글에서는 LLM의 응답 정확도와 동작을 최적화할 때 판단의 기준이 되는 사고 틀을 소개합니다. 프롬프트 엔지니어링, 검색 증강 생성(RAG), 파인튜닝을 살펴보고, 각 기법을 언제 어떻게 사용하는지와 주의할 점을 설명합니다.

이 글을 읽으면서 각 원칙을 자신의 사용 사례에 비추어 보고, 그 사례에서 정확도가 무엇을 뜻하는지 생각해 보세요. 사람이 광고 문구를 다시 써야 하는 경우와 고객에게 100달러를 환불해야 하는데 1,000달러를 환불하는 경우는 잘못된 결과가 미치는 영향이 다릅니다. LLM의 정확도를 논의할 때는 실패 한 건에 드는 비용과 성공 한 건으로 절감하는 비용이나 얻는 수익을 대략적으로라도 파악해야 합니다. 글의 마지막에서 프로덕션에 ‘충분한’ 정확도를 다룰 때 이 문제를 다시 살펴봅니다.

LLM 최적화를 바라보는 관점

많은 실무 가이드에서는 최적화를 단순한 순서로 설명합니다. 프롬프트 엔지니어링으로 시작해서 검색 증강 생성을 거친 다음 파인튜닝으로 넘어가는 식입니다. 하지만 실제로는 이 순서를 따르지 않는 경우가 많습니다. 각 기법이 해결하는 문제가 다르므로, 개선하려는 문제에 맞춰 기법을 선택해야 합니다.

LLM 최적화를 두 축으로 나누어 생각하면 이해하기 쉽습니다.

일반적인 LLM 작업은 왼쪽 아래의 프롬프트 엔지니어링에서 시작합니다. 여기서 테스트하고 결과를 분석·평가해 기준 성능을 정합니다. 그런 다음 평가 사례를 검토하고 오답이 나온 이유를 파악해 어느 축을 최적화할지 결정합니다.

• 컨텍스트 최적화: 1) 필요한 배경지식이 학습 데이터에 없거나, 2) 모델이 아는 정보가 오래되었거나, 3) 작업에 비공개 정보가 필요한 경우에는 컨텍스트를 최적화해야 합니다. 이 축에서는 응답 정확도를 최대한 높입니다.
• LLM 최적화: 1) 결과가 일관되지 않고 형식이 잘못되거나, 2) 말투나 문체가 적절하지 않거나, 3) 모델이 요구된 추론 절차를 일관되게 따르지 않는 경우에는 LLM을 최적화해야 합니다. 이 축에서는 동작 일관성을 최대한 높입니다.

실제 최적화는 여러 단계에 걸쳐 진행됩니다. 성능을 평가하고 개선 방법에 대한 가설을 세운 뒤, 그 방법을 적용하고 다시 평가해 다음 단계를 결정합니다. 다음은 일반적인 최적화 플로우의 예입니다.

이 예에서는 다음 순서로 진행합니다.

• 프롬프트를 작성하고 성능을 평가합니다.
• 고정된 퓨샷 예시를 추가해 결과의 일관성을 높입니다.
• 질문에 맞춰 퓨샷 예시를 동적으로 가져오는 검색 단계를 추가합니다. 입력마다 관련 컨텍스트를 제공해 성능을 높입니다.
• 예시 50개 이상으로 데이터셋을 구성하고 모델을 파인튜닝해 일관성을 높입니다.
• 검색을 조정하고 사실 확인 단계를 추가해 환각을 찾아내고 정확도를 높입니다.
• 개선된 RAG 입력을 포함하는 새 학습 예시로 파인튜닝한 모델을 다시 학습시킵니다.

까다로운 비즈니스 문제를 풀 때 흔히 사용하는 최적화 파이프라인입니다. 더 관련성 높은 컨텍스트가 필요한지, 모델이 더 일관되게 동작해야 하는지 판단하는 데 도움이 됩니다. 이 판단이 서면 최적화의 첫 단계에서 무엇을 조정할지도 알 수 있습니다.

이제 이 틀을 바탕으로 각 영역을 실제로 최적화하는 방법을 살펴보겠습니다. 왼쪽 아래의 프롬프트 엔지니어링부터 시작합니다.

프롬프트 엔지니어링

일반적으로 가장 좋은 출발점은 프롬프트 엔지니어링입니다**. 요약, 번역, 코드 생성처럼 제로샷으로도 프로덕션에 필요한 정확도와 일관성을 달성할 수 있는 작업에서는 이 방법만으로 충분한 경우가 많습니다.

프롬프트 엔지니어링으로 시작하면 해당 사용 사례에서 정확도가 무엇인지부터 정의하게 됩니다. 가장 기본적인 단계는 모델에 입력을 제공하는 것이므로, 그 출력이 기대에 부합하는지 판단할 수 있어야 합니다. 원하는 결과가 나오지 않았다면 왜 그런지 살펴보세요. 그 이유가 다음에 어떤 최적화 방법을 써야 할지 알려줍니다.

항상 간단한 프롬프트와 기대하는 출력부터 정하세요. 그런 다음 원하는 결과가 나올 때까지 컨텍스트, 지침, 예시 등을 추가하며 프롬프트를 개선하세요.

최적화

여기서는 OpenAI API 문서의 프롬프트 엔지니어링 가이드에 나온 전략을 중심으로 프롬프트를 최적화합니다. 각 전략으로 컨텍스트나 LLM을 조정할 수 있으며, 두 가지 모두에 적용되는 전략도 있습니다.

전략만 보고는 어떻게 적용할지 감이 오지 않을 수 있습니다. gpt-4-turbo로 아이슬란드어 문장을 교정하는 예를 통해 실제 적용 방법을 살펴보겠습니다.

SYSTEM: The following sentences contain Icelandic sentences which may include errors. Please correct these errors using as few word changes as possible.

# Examples
USER: "Stofnendurnir séu margir og eru fulltrúar hennar frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."
ASSISTANT: "Hann segir að stofnendur leynireglunnar séu margir og að fulltrúar hennar séu frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."

USER: "Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstormar (fræðiheiti: Polychatete)."
ASSISTANT: "Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstaormar (fræðiheiti: Polychatete)."

USER: "Sörvistölur eru nær hálsi og skartgripir kvenna á brjótsti."
ASSISTANT: "Sörvistölur eru nær hálsi og skartgripir kvenna á brjósti."

USER: [input user query here]

프롬프트 엔지니어링은 좋은 출발점이며, 적절한 조정 방법을 선택하면 성능을 상당히 높일 수 있습니다.

다만 프롬프트 엔지니어링은 적용 범위를 넓히기 어렵다는 한계가 있습니다. 프롬프트에 내용을 직접 추가하는 것만으로 감당하기 어려울 만큼 다양한 문제를 처리하려면 컨텍스트를 동적으로 제공해야 합니다. 또는 퓨샷 예시로 달성할 수 있는 수준보다 더 일관된 동작이 필요할 수도 있습니다.

그렇다면 프롬프트 엔지니어링만으로 어디까지 성능을 높일 수 있을까요? 사용 사례마다 다르므로 평가를 통해 판단해야 합니다.

평가

따라서 이 단계에서 얻을 수 있는 가장 좋은 결과물은 잘 다듬은 프롬프트와 질문·정답 쌍으로 구성된 평가 세트입니다. 질문과 정답을 20쌍 이상 확보하고, 실패 사례를 자세히 분석해 원인에 대한 가설까지 세웠다면 더 고도화된 최적화 방법을 시도할 기준이 마련된 것입니다.

더 복잡한 최적화 방법으로 넘어가기 전에 평가를 자동화해 개선 주기를 단축하는 방법도 고려해 보세요. 다음은 실제로 효과가 있었던 방법입니다.

• ROUGE나 BERTScore 같은 지표로 대략적인 판단을 내립니다. 사람의 평가와 상관관계가 그리 높지는 않지만, 한 차례 개선을 거친 뒤 모델 출력이 얼마나 달라졌는지 빠르고 효과적으로 측정할 수 있습니다.
• G-Eval 논문에서 설명한 대로 GPT-4를 평가자로 사용합니다. LLM에 채점 기준표를 제공해 출력을 최대한 객관적으로 평가하게 합니다.

각 방법을 더 자세히 알아보려면 실제 적용 과정을 안내하는 쿡북 예제를 참고하세요.

최적화 도구 이해하기

프롬프트 엔지니어링을 마치고 평가 세트도 갖췄지만 모델이 여전히 기대한 대로 동작하지 않을 수 있습니다. 이때 가장 중요한 일은 모델이 어디서 실패하는지 진단하고 그 문제를 해결하는 데 가장 적합한 도구를 찾는 것입니다.

다음은 진단에 사용할 수 있는 기본 틀입니다.

모델이 틀린 평가 문항을 컨텍스트로 제공하는 기억의 문제와 학습으로 익히는 기억의 문제로 나누어 생각해 볼 수 있습니다. 시험을 본다고 가정해 보세요. 정답을 맞히는 방법에는 두 가지가 있습니다.

• 지난 6개월간 수업을 들으며 특정 개념이 어떻게 적용되는지 여러 예시로 반복해서 익혔습니다. 이것이 학습으로 익히는 기억입니다. LLM에는 프롬프트와 기대하는 응답의 예시를 보여주고, 모델이 그 예시에서 배우도록 합니다.
• 시험장에 교과서를 가져와 답에 필요한 정보를 찾아볼 수 있습니다. 이것이 컨텍스트로 제공하는 기억입니다. LLM에는 관련 정보를 컨텍스트 윈도우에 넣어 줍니다. 프롬프트 엔지니어링으로 고정된 정보를 제공하거나, RAG로 이 과정을 대규모로 처리할 수 있습니다.

두 최적화 방법은 함께 사용해 효과를 더할 수 있습니다. 사용 사례에 따라 최상의 성능을 내려면 두 방법을 함께 써야 할 수도 있습니다.

먼저 단기 기억에 해당하는 문제를 해결해야 한다고 가정해 보겠습니다. 이때는 RAG를 사용합니다.

검색 증강 생성(RAG)

RAG는 콘텐츠를 검색(Retrieval)해 LLM의 프롬프트를 보강(Augmentation)한 뒤 답변을 생성(Generation)하는 과정입니다. 이를 통해 모델은 작업에 필요한 도메인별 컨텍스트를 활용할 수 있습니다.

RAG는 LLM의 정확도와 일관성을 높이는 데 매우 유용합니다. OpenAI의 대규모 고객 배포 사례 중 상당수는 프롬프트 엔지니어링과 RAG만으로 구현했습니다.

이 예에서는 통계 자료로 구성된 지식 베이스를 미리 임베딩했습니다. 사용자가 질문하면 질문도 임베딩한 뒤 지식 베이스에서 가장 관련성 높은 내용을 검색합니다. 모델은 검색 결과를 받아 질문에 답합니다.

RAG 애플리케이션에서는 검색이라는 최적화 축이 하나 더 생깁니다. RAG가 제대로 동작하려면 모델에 적절한 컨텍스트를 제공하고, 모델이 이를 바탕으로 정확하게 답하는지도 평가해야 합니다. 두 가지를 격자로 나타내면 RAG 평가를 쉽게 이해할 수 있습니다.

RAG 애플리케이션에서 문제가 발생할 수 있는 영역은 두 가지입니다.

처음에 살펴본 원칙은 그대로 적용됩니다. 평가로 무엇이 잘못되었는지 파악하고, 그 문제를 해결하는 방향으로 최적화합니다. RAG에서 달라지는 점은 검색도 함께 고려해야 한다는 것입니다.

RAG가 해결하는 것은 컨텍스트 내 학습 문제입니다. 하지만 많은 사용 사례에서는 LLM이 작업 자체를 익혀 일관되고 안정적으로 수행하도록 하는 것이 과제입니다. 이 문제에는 파인튜닝을 사용합니다.

파인튜닝

학습으로 익히는 기억의 문제를 해결하기 위해 많은 개발자가 특정 도메인에 맞춘 소규모 데이터셋으로 LLM을 추가 학습시킵니다. 이렇게 모델을 특정 작업에 맞게 최적화하는 과정을 파인튜닝이라고 합니다.

파인튜닝의 목적은 대개 다음 두 가지 중 하나입니다.

• 특정 작업의 모델 정확도 향상: 해당 작업을 올바르게 수행한 예시를 모델에 많이 보여주고 학습시켜, 모델이 그 작업을 제대로 익히도록 합니다.
• 모델 효율 향상: 더 적은 토큰이나 더 작은 모델로 같은 정확도를 달성합니다.

파인튜닝의 첫 단계는 학습 예시로 데이터셋을 구성하는 것입니다. 예시가 모델이 실제 환경에서 접할 입력을 정확히 반영해야 하므로 가장 중요한 단계입니다.

데이터를 정제했으면 학습을 실행해 파인튜닝한 모델을 만들 수 있습니다. 학습에 사용하는 플랫폼이나 프레임워크에 따라 다른 머신 러닝 모델처럼 하이퍼파라미터를 조정할 수도 있습니다. 과적합을 감지하려면 학습 후 평가에 사용할 데이터를 항상 별도로 남겨 두는 것이 좋습니다. 좋은 학습 세트를 구성하는 방법은 파인튜닝 문서의 가이드를 참고하세요. 학습이 끝나면 새로 파인튜닝한 모델을 추론에 사용할 수 있습니다.

여기서는 OpenAI의 모델 맞춤화 기능을 사용할 때 효과적이었던 방법을 중심으로 파인튜닝 최적화를 살펴봅니다. 같은 원칙을 다른 제공업체나 오픈 소스 도구에도 적용할 수 있습니다. 다음 사항을 고려하세요.

• 프롬프트 엔지니어링부터 시작하세요. 프롬프트 엔지니어링 단계에서 신뢰할 수 있는 평가 세트를 마련해 기준으로 삼으세요. 이렇게 하면 기본 프롬프트에 확신이 생길 때까지 적은 비용으로 실험할 수 있습니다.
• 적은 수의 예시로 시작하고 품질에 집중하세요. 기반 모델을 파인튜닝할 때는 학습 데이터의 양보다 품질이 중요합니다. 예시 50개 이상으로 시작해 평가하세요. 목표 정확도에 미치지 못하고 오답의 원인이 컨텍스트가 아니라 동작이나 일관성에 있다면 학습 세트를 늘리세요.
• 실제 입력을 대표하는 예시를 사용하세요. 흔한 실수 중 하나는 파인튜닝 예시의 형식이나 구성이 모델이 프로덕션에서 접하는 입력과 미묘하게 다른 것입니다. 예를 들어 RAG 애플리케이션이라면 RAG 입력이 포함된 예시로 파인튜닝하세요. 그래야 모델이 프로덕션에서 컨텍스트 활용법을 제로샷으로 알아내야 하는 상황을 피할 수 있습니다.

여러 기법 함께 사용하기

이 기법들은 함께 사용할 수 있습니다. 초기 평가에서 컨텍스트와 동작 모두에 문제가 드러났다면 프로덕션 솔루션에서 파인튜닝과 RAG를 함께 사용하게 될 가능성이 큽니다. 두 방법을 결합하면 서로의 약점을 보완할 수 있습니다. 주요 이점은 다음과 같습니다.

• 파인튜닝으로 프롬프트 엔지니어링에 사용하는 토큰 수를 최소화합니다. 프롬프트에 넣던 지침과 퓨샷 예시를 다수의 학습 예시로 대체해 모델이 일관된 동작을 익히도록 합니다.
• 충분한 파인튜닝으로 복잡한 동작을 학습시킵니다.
• RAG로 컨텍스트를 추가합니다. 최신 콘텐츠나 사용 사례에 필요한 전문 정보를 제공할 수 있습니다.

# One training example
SYSTEM: The following sentences contain Icelandic sentences which may include errors. Please correct these errors using as few word changes as possible.
USER: "Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum í heiminum."
ASSISTANT: "Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum heims."

지금까지 RAG와 파인튜닝이 각각 어떤 상황에 적합한지 살펴봤습니다. 마지막으로 고려할 점은 이런 도구를 도입하면 한 차례 개선을 마치는 데 걸리는 시간이 늘어날 수 있다는 것입니다.

• RAG를 사용하면 LLM의 동작뿐 아니라 검색도 조정해야 합니다.
• 파인튜닝한 모델을 추가로 조정하려면 파인튜닝을 다시 실행하고 학습 세트와 검증 세트도 관리해야 합니다.

두 과정 모두 복잡하고 시간이 오래 걸릴 수 있습니다. LLM 애플리케이션이 복잡해지면 기존에 잘되던 작업의 성능이 떨어지는 회귀 문제도 생길 수 있습니다. 복잡한 RAG나 파인튜닝을 도입하기 전에 기본적인 방법으로 정확도를 최대한 높이세요. 더 정교해 보인다는 이유만으로 RAG와 파인튜닝을 함께 도입하기보다는 목표 정확도를 기준으로 방법을 선택하세요.

프로덕션에는 어느 정도의 정확도가 충분할까?

LLM의 정확도를 높이는 작업에는 끝이 없을 수 있습니다. 범용 기법만으로 99.999%의 정확도에 도달할 가능성은 낮습니다. 그렇다면 어느 정도면 충분할까요? 이 절에서는 LLM을 프로덕션에 적용해도 되겠다고 판단하는 방법과 배포한 솔루션의 위험을 관리하는 방법을 살펴봅니다.

이 문제는 비즈니스와 기술 두 관점에서 살펴보는 것이 좋습니다. 고객 서비스 헬프데스크 사례를 통해 두 관점에서 위험을 관리하는 전반적인 접근법을 설명하겠습니다.

비즈니스 관점

규칙 기반 시스템이나 기존 머신 러닝 시스템, 또는 사람에게 일을 맡기던 기업은 결과를 비교적 쉽게 예측할 수 있었습니다. 반면 LLM은 어떤 형태로 실패할지 미리 알기 어려워 기업이 믿고 일을 맡기기 쉽지 않습니다.

고객 서비스 사례에서 효과가 있었던 접근법은 다음과 같습니다.

먼저 주요 성공 사례와 실패 사례를 파악하고 각각의 예상 절감액이나 비용을 산정합니다. 그러면 파일럿 운영 성과를 바탕으로 솔루션을 도입했을 때 얼마나 절감하거나 지출할지 구체적으로 설명할 수 있습니다.

• 예를 들어 기존에는 상담원이 해결하던 문의를 AI가 해결하면 건당 $20를 절감할 수 있습니다.
• 상담원이 처리할 필요가 없는 문의를 상담원에게 이관하면 건당 비용이 $40 정도 들 수 있습니다.
• 최악의 경우 AI 응대에 크게 불만을 느낀 고객이 이탈해 건당 $1000의 손실이 발생합니다. 여기서는 AI가 문의를 해결하지 못한 경우의 5%에서 고객이 이탈한다고 가정합니다.

또한 솔루션의 전반적인 영향을 파악하기 위해 실제 운영 지표를 측정했습니다. 고객 서비스라면 다음과 같은 지표를 사용할 수 있습니다.

• 상담원만 응대한 경우와 AI가 응대한 경우의 고객 만족도(CSAT) 점수
• 처리한 문의를 사후 검토해 측정한 상담원과 AI의 판단 정확도
• 상담원과 AI가 각각 문의를 해결하는 데 걸린 시간

고객 서비스 사례에서는 몇 차례 파일럿을 거쳐 명확한 데이터를 확보한 뒤 두 가지 중요한 결정을 내렸습니다.

1. LLM 솔루션이 기대보다 자주 문의를 상담원에게 이관하더라도 기존 솔루션보다 운영 비용을 크게 줄일 수 있었습니다. 따라서 나머지 15%가 주로 문의를 일찍 이관한 경우라면 정확도가 85%여도 받아들일 만했습니다.
2. 사기 관련 문의를 잘못 처리하는 경우처럼 실패 비용이 매우 크면 상담원이 판단을 주도하고 AI가 보조하도록 했습니다. 이때는 판단 정확도 지표를 근거로 AI에 전적으로 맡기기 어렵다는 결론을 내렸습니다.

기술 관점

기술 측면에서 할 일은 좀 더 분명합니다. 비즈니스 측에서 기대하는 가치와 실패 비용을 파악했다면, 기술팀은 문제가 발생해도 사용자 경험을 해치지 않고 대응할 수 있는 솔루션을 구축해야 합니다.

다시 고객 서비스 사례를 살펴보겠습니다. 모델이 고객의 의도를 85%의 정확도로 파악한다고 가정하면, 기술팀은 다음과 같은 방법으로 나머지 15%의 오판이 미치는 영향을 줄일 수 있습니다.

• 모델이 의도를 확신하지 못할 때는 고객에게 추가 정보를 요청하도록 프롬프트를 설계할 수 있습니다. 첫 시도의 정확도는 떨어질 수 있지만, 의도를 판단할 기회가 두 번 주어지면 최종 정확도가 높아질 수 있습니다.
• 2차 응대를 맡는 어시스턴트가 문의를 의도 파악 단계로 되돌릴 수 있게 합니다. 사용자의 대기 시간은 조금 늘어나지만, 응대 과정에서 잘못된 판단을 바로잡을 기회가 생깁니다.
• 의도가 불분명하면 상담원에게 이관하도록 프롬프트를 설계할 수 있습니다. 단기적으로는 운영 비용 절감 효과가 줄지만 장기적으로는 고객 이탈 위험을 줄일 수 있습니다.

이러한 결정은 사용자 경험에 반영됩니다. 정확도를 높이는 과정에서 응대가 느려지거나 상담원 개입이 늘어날 수 있으며, 그 영향은 앞서 비즈니스 절에서 살펴본 비용 모델에도 반영됩니다.

이렇게 비즈니스 결정과 기술적 결정을 나누어 검토하면 실제 운영 여건에 맞는 정확도 목표를 세울 수 있습니다.

실제 작업에 적용하기

지금까지 LLM의 정확도를 최대한 높이기 위한 사고 틀과 활용할 수 있는 도구, 프로덕션에 충분한 정확도를 판단하는 방법을 살펴봤습니다. 이 틀과 도구를 활용하면 프로덕션에 필요한 성능을 갖출 때까지 체계적으로 개선할 수 있습니다. 다른 팀이 이 기법으로 어떤 성과를 냈는지 궁금하다면 Morgan Stanley와 Klarna의 고객 사례를 살펴보세요.

여러분의 프로젝트가 잘되기를 바랍니다. 이 방법으로 어떤 서비스를 만드실지 기대하겠습니다!