Skip to main content

GenAI 프로젝트의 라이프사이클

LLM으로 구축해야 하는 이유, LLM으로 구축하는 방법, 그리고 LLM 기반 구축에 필요한 구성 요소에 대한 입문서 이 글은 AI로 번역되었습니다. 오역이 있을 수 있으니 댓글로 알려주세요.
Created on September 15|Last edited on September 15
지난달, 우리는 출시했습니다 함께 LLM 앱을 만들어 갈 연재의 첫 글입니다. 우리는 모델을 가져와서 정확도 17%에서 90% 이상으로 프로젝트 범위를 제대로 정하고 체인 오브 소트를 활용해 프롬프트를 조정하며 명확한 예시를 제공하는 것만으로도 가능합니다.
아직 다루지 않은 한 가지가 있습니다. 바로 GenAI 프로젝트의 라이프사이클과 왜 그렇게 많은 기업들이 우리와 같은 프로젝트를 최우선으로 추진하는가입니다. 오늘은 그 이야기를 하려 합니다. 먼저 LLM으로 구축할 때의 이점을 설명하고, 이어서 일반적인 진행 단계를 순서대로 살펴보겠습니다. 이는 W&B에서 내부 프로세스를 위해 LLM을 구축해 온 우리의 경험과, 지금 이 순간 고객들이 실제로 하고 있는 작업에서 얻은 통찰을 바탕으로 합니다.
곧 그 글의 후속편으로 돌아오겠습니다. 그동안에는, 왜 그런지부터 살펴봅시다.

목차



LLM으로 구축해야 하는 이유

간단히 말해, LLM은 누구나 유용한 애플리케이션을 빠르게 만들 수 있도록 엄청나게 가속해 줍니다. 전통적인 머신러닝에서는 유용한 모델을 프로덕션에 올리기까지, 데이터 수집부터 모델 학습, 파인튜닝, 배포에 이르기까지 전 과정에 몇 달이 걸렸습니다. 반면 많은 LLM에서는 좋은 프롬프트를 작성하고 몇 분 만에 자신에게 맞는 프롬프트를 찾아낼 때까지 반복할 수 있습니다. 보통은 몇 시간 안에 모델에 API 호출을 시작하고 추론까지 진행할 수 있습니다.

또한 LLM에서 뛰어난 결과를 얻기 위해 딥러닝 모델, 프로그래밍, 수학이나 통계에 대한 지식이 꼭 필요한 것도 아닙니다. 자연어로 간단히 상호작용하면 됩니다. 즉, 누구나 이 기술에서 막대한 가치를 얻을 수 있습니다. 그리고 2024년 초에는 ChatGPT가 다른 모델들보다 훨씬 뛰어났지만, 오픈 소스 프로젝트들이 빠르게 따라잡으면서 Mistral과 같은 선택지가 비용을 크게 늘리지 않고도 모델을 구축하기에 매우 이상적인 대안이 되었습니다.
더 빠르고 코딩 실력이 덜 필요하다는 점 외에도, LLM에는 전통적인 소프트웨어와 다른 점이 하나 더 있습니다: 소프트웨어에서는 애플리케이션을 만들어 내는 코드가 곧 결과물입니다. 하지만 LLM에서는 결과물이 그 과정에서 시도한 모든 것들입니다. — 데이터, 프롬프트, 파이프라인, 평가 지표 등. 이런 실험과 배움 전반을 회사의 IP로 생각해야 합니다. 이것이 사람들이 LLM을 활용하는 이유 그 자체는 아니더라도, 구축 과정에서 반드시 염두에 둘 중요한 사항입니다.
다음으로, 이러한 프로젝트에서 일반적으로 거치는 단계들을 살펴보겠습니다.

LLM 생애주기: 아이디어에서 프로덕션까지

아래 그림은 일반적인 LLM 프로젝트 생애주기를 보여줍니다. 보라색 구간에서는 상당한 반복(iteration)이 있음을 염두에 두세요.


1. 범위를 정의하기

이 부분은 이전 글에서 더 자세히 다뤘지만, 여기서 다시 강조할 가치가 있습니다. 처음에는 범위를 최대한 좁게 정의해야 합니다. 시작부터 크고 복잡한 문제 전반을 공략하면 좌절하기 쉽습니다. 반대로, 문제의 작은 부분에서 높은 정확도를 달성하면 개선해 갈 수 있는 기준선이 생기고, 동시에 데이터와 프로젝트의 전반적 방향성도 검���할 수 있습니다.
사용 사례의 범위를 명확히 정의하면 어떤 크기의 모델이 요구 사항에 가장 잘 맞는지 선택하는 데도 도움이 됩니다. 이 단계에서 프롬프트 엔지니어링으로 시작할지, 기성(off-the-shelf) 모델을 파인튜닝할지, 아니면 아예 처음부터 자체 모델을 학습할지 결정하게 됩니다. 단순한 번역이나 요약 작업이라면 기성 모델만으로도 충분할 수 있습니다. 특정한 톤으로 응답하게 하거나 사유 데이터에 관한 질문에 답하도록 하려면 파인튜닝을 검토할 가치가 있습니다. 모델이 무엇을 해야 하는지 구체적으로 정의해 두면 시간과 연산 비용을 모두 절약할 수 있습니다.

2. 프롬프트 엔지니어링

지난 글에서 우리는 영리한 프롬프트 엔지니어링 몇 가지 조정만으로 정확도를 17%에서 90%를 훌쩍 넘기는 수준까지 끌어올렸습니다. 프롬프트 엔지니어링은 다소 ‘예술’적이지만, 충분히 직관적입니다. 프롬프트를 바꿀 때마다 모델이 어떻게 달라지는지 가늠하고, 효과가 좋은 전술에는 과감히 힘을 실으세요. 결국 성능이 더 기술적인 개선으로 넘어가기 전에 정체 구간을 맞는 순간이 오겠지만, 프롬프트만으로도 전체 성능에 정말 큰 변화를 만들어낼 수 있다는 점을 분명히 기억해야 합니다.

3. 파인튜닝

일부 작업은 초기에 파인튜닝이 필요할 수 있습니다. 보통 이는 LLM이 사용자와 유사한 데이터를 충분히 보지 못한 작업일 때 해당합니다. 예를 들어 사내 영업 데이터 같은 사유 데이터나 규제상의 가드레일 때문에 접근이 제한된 의료 데이터가 그럴 수 있습니다. 파인튜닝은 일반 LLM을 새로운 데이터로 학습시켜, 특정 문제에 대한 성능을 향상시키는 방법일 뿐입니다.

4. 평가하기

모델 성능을 제대로 평가할 방법이 없으면 중요한 학습 기회를 잃고, 수행하는 모든 실험이 무의미해집니다. LLM 애플리케이션을 구축하는 동안은 물론, 프로덕션에서 앱이 실행될 때에도 모델을 평가해야 합니다. 또한 환각 경향과 같은 모델의 한계를 점검하고, 이를 방지하기 위한 페일세이프를 설계할 필요가 있습니다.
간단히 말해, 사용자 정의 지표나 벤치마크로 모델 성능을 평가하면 시도하는 다양한 기법을 서로 비교할 수 있고, 실제 프로덕션 환경에서 유용하게 작동할 것을 확신할 수 있습니다.

5. 반복하기

마지막 세 단계를 한 번만 거쳐서는 만족할 만한 성능이 나오지 않을 가능성이 큽니다. 프롬프트를 다듬고, 파인튜닝을 수행하고, 초기 기준선과 다시 비교 평가해야 합니다. 이는 앞서 언급했듯이 매우 중요한 부분으로, 이 과정에서 쌓이는 것들이 사실상 여러분 회사의 IP입니다. 여기서 얻은 학습을 바탕으로 더 복잡한 LLM 애플리케이션을 구축하거나 새로운 프로젝트를 시작할 수 있습니다.

6. 배포하기

수용 가능한 성능의 모델을 확보했다면, 배포를 위해 최적화하여 연산 자원을 가장 효율적으로 활용하도록 만들고, 이를 우리의 앱에 배포할 수 있습니다.

LLM 앱의 기본 구성 요소

이제 왜와 어떻게를 이해했으니, 무엇을 만들지—우리의 LLM 앱—에 대해 살펴봅시다. 숙련된 개발자라면 이미 익숙한 개념이 많겠지만, 이제 막 만들기에 도전하려는 분이라면 먼저 아래 아이디어들을 익혀 두는 것을 권합니다. 이 내용들은 앞으로 계속 반복해서 다루게 될 것입니다!

프롬프트

프롬프트는 LLM에 예측(출력)을 생성하도록 우리가 제공하는 지시문입니다. 좋은 재료로 더 맛있는 음식을 만들 듯이, LLM에 더 명확한 지시를 내릴수록 더 나은 출력이 나옵니다.

일반적인 프롬프트는 보통 세 가지 핵심 구성 요소로 이루어집니다:

시스템 메시지

이는 어시스턴트의 톤, 성격, 전반적인 동작 방식을 설정합니다. 또한 대화 내내 어떻게 행동해야 하는지에 대한 구체적인 지시를 제공하는 데 사용할 수 있습니다(예: LLM이 학습한 일반 지식이 아니라, 당신의 특정 문제에 대한 질문에만 답하도록 제한). 시스템 메시지는 사용자에게 보이지 않지만, 우리의 고유한 사용 사례에 맞게 LLM의 동작을 조정할 수 있게 해줍니다. 예: “당신은 바둑 전문가입니다.”

사용자 메시지

시스템 메시지에서 정의한 상위 수준의 동작에 따라 수행할 구체적인 지시입니다. 예를 들어, 여기에 사용자의 질문이 들어갑니다. 예: “이 바둑판을 보고 한 수 두세요. … <바둑판>”

어시스턴트

이것을 사용하면 봇에게 이전에 했던 발화를 다시 제공해 대화를 이어갈 수 있습니다. ChatGPT를 사용해 본 적이 있다면 익숙할 것입니다. 예: 지금까지의 바둑 진행 예시.

토큰

컨텍스트 윈도우는 보통 토큰 단위로 측정됩니다. 토큰은 모델이 읽거나 생성하는 텍스트의 조각입니다. 토큰은 일반적으로 하나의 단어가 아니라 문자, 단어의 일부 같은 더 작은 단위이거나, 덜 일반적으로는 전체 구 같은 더 큰 단위일 수 있습니다. 이미지에서, 당신이 입력한 텍스트가 모델에 의해 토큰으로 어떻게 분할되는지 몇 가지 예를 확인할 수 있습니다.


모델 파라미터

파라미터를 모델의 메모리라고 생각하세요. 파라미터가 많을수록 메모리가 커지고, 그만큼 모델은 더 정교한 작업을 수행할 수 있습니다.

완성과 추론

마지막으로, 모델의 출력은 완성입니다. 모델을 사용해 텍스트를 생성하는 행위는 추론입니다.

결론

이제 사람들이 왜 LLM 애플리케이션을 만들고 있는지, 그리고 이러한 앱의 주요 구성 요소와 라이프사이클을 이해했으니, 실제 프로젝트로 들어가 보세요! 고객 성공 티켓 분류기를 만들기 시작했습니다 그리고 진행하면서 위의 각 단계를 자세히 살펴볼 예정입니다. 첫 번째 글에서는 프롬프트 엔지니어링에 초점을 맞추고, 범위를 정의하며, 간단한 평가 하니스 구축까지 다룹니다.
반대로, 지금 바로 시작하고 싶다면 저희의 무료 강의인 “LLM 앱 만들기”를 확인해 보시길 권합니다.
다음에 또 만나요!


이 글은 AI로 번역되었습니다. 오역이 의심되는 부분이 있으면 댓글로 알려 주세요. 원문 보고서는 아래 링크에서 확인할 수 있습니다: 원문 보고서 보기