LLM 챗봇은 우리 비즈니스 특성을 고려해서 답변해줄 수 있을까?

Hyemin Park, Sungjoon Park and Jihyung Moon

June 8, 2023

ChatGPT, PaLM2과 같은 LLM의 등장으로 LLM에게 궁금한 점을 물어보고, 문장을 작성하게 하는 등 너도 나도 신기하고 재미있는 챗봇을 개발하고 있는 것처럼 보이는 요즘입니다. 한편으로는, 최근 “LLM 챗봇이 과연 우리 회사의 비즈니스 특성을 고려해서 답변해 줄 수 있을까?” 고민하시는 분들을 자주 만나게 됩니다.

결론부터 말하자면 답은 “네”입니다. LLM에게 명령(instruction)을 어떻게 제공하는지, 필요한 배경 지식을 어떻게 제공하는지에 따라서 LLM 챗봇의 답변을 내가 원하는 방향으로 유도할 수 있습니다. 특히, 기업이 LLM 챗봇을 도입할 때 우리 회사의 내부 정책, 슬로건, 제품 특성 등, LLM에게 필요한 배경 지식을 적절하게 제공하게 되면, 기업의 고객들이 챗봇에게 기대하는 답변을 이끌어낼 수 있습니다.

예를 들어, 커머스 회사의 CS(Customer Support) 챗봇은 우리 회사의 자주 묻는 질문(이하 ‘FAQ’)과 교환/반품/취소 정책들을 잘 숙지하고 있어야 하고, 세일즈 챗봇은 우리 회사의 제품 정보뿐만 아니라, 잠재 고객과의 이전 대화 기록을 참고하여 답변할 수 있어야 합니다.

하지만 기업 내 많은 정보들이 정형화되지 못한 상태로 쌓여있는 현실을 고려했을 때, 원하는 답변을 유도하는 것이 말처럼 쉽지만은 않습니다. 특히, LLM만을 사용해서 원하는 답변을 유도하는 방식들은 비용 혹은 성능 측면에서 한계가 있습니다. 왜냐하면 기업이 LLM 챗봇에게 제공하고자 하는 배경 지식은 LLM이 사전학습 과정에서 학습하지 못한 외부 지식(External Knowledge)일 가능성이 높고, 참고해야 하는 외부 지식의 양이 적지 않을 것이기 때문입니다. 이미 방대한 양의 데이터를 학습한 LLM에게 적지 않은 외부 지식을 참고하게 만드는 것은 기술 구현 측면에서 여러가지 어려움이 존재합니다.

본 포스트에서는 ChatGPT, PaLM2 같은 상용 LLM이 사전학습하지 않은 외부 지식을 바탕으로 답변을 생성하게 만들기 위한 시도들은 어떤 것이 있으며, 어떤 한계점들이 있는지 소개하고, SoftlyAI가 어떤 배경에서 비즈니스 use case에 맞는 LLM을 기업들에게 제공하기 위한 Retrieval-augmented Generation 시스템을 개발하게 되었는지 설명드리려고 합니다.

사전학습 데이터에 제한된 지능

잘 알려져 있다시피 상용 LLM들은 특정 시점까지 수집된 데이터를 기반으로 학습되어 있기 때문에 학습 시점까지의 지식을 스냅샷 형태로 담고 있습니다. 그렇기 때문에 학습 시점 이후에 발생한 정보, 혹은 상용 LLM 개발 과정에서 접근할 수 없었던 정보에 대해서는 답변을 생성하는 데 어려움이 있습니다.

1) 학습 시점 이후의 정보를 모릅니다.

올해 초 출시된 GPT-4는 2021년까지의 데이터를 기반으로 학습되었는데요. ‘뉴진스가 누구야?’에 대해서 물어보니 모른다고 합니다. 아이돌 그룹 뉴진스(NewJeans)는 2022년에 데뷔했기 때문입니다.

2) 우리 회사 비즈니스 맥락을 모릅니다.

우리 회사의 비즈니스 정책, 고객 대응 절차와 같은 내부용 문서들은 공개된 데이터가 아닌 만큼 LLM이 사전학습 과정에서 학습하지 못했거나, 학습한 데이터 내 비중이 낮을 가능성이 큽니다. FAQ, 제품 정보 등은 공개되어 있다 하더라도 지속적으로 업데이트 되며, 온라인에 존재하는 수많은 FAQ 중 하나이기 때문입니다. 그렇기 때문에 우리 회사 비즈니스 맥락을 특정하여 답변을 생성하지 못합니다.

예를 들어, 아래와 같이 ‘인증 메일’에 대한 문의를 했을 때 우리 회사의 인증 메일 정책에 대해서 알려주는 대신, 일반적인 환불에 대한 답변을 반환합니다.

LLM이 배우지 않은 외부 지식을 참고하게 만드는 방식

이러한 한계들로 인해, 상용 LLM이 사전학습한 데이터가 아닌, 외부 지식을 참고해서 답변을 생성하도록 유도하기 위해서는 필요한 지식을 주입시키는 작업이 필요합니다. 다양한 방식이 존재하지만, 본 포스트에서는 최근 LLM을 이야기할 때 자주 언급되는 두 가지 방식을 탐구해보고자 합니다.

데이터를 추가로 학습시키는 Fine-tuning 방식
프롬프트 엔지니어링(Prompt Engineering) 방식

그러나 이 두 가지 방식 모두 우리 회사 맥락에 맞는 LLM을 도입하기 위해 외부 지식을 정확하고 경제적으로 참고하는데 고유한 한계점들을 가지고 있습니다. 이러한 한계점들을 극복할 수 있는 Retrieval-augemented Generation 방식의 필요성에 대해서도 설명드리겠습니다.

1) Fine-tuning

ChatGPT는 사용자들이 자체 데이터를 활용하여 Fine-tuning 할 수 있는 기능을 제공합니다. 위 그림과 같이 외부 지식을 활용하여 LLM 학습용 데이터를 직접 제작하고 LLM을 학습시키는 방식인데요.

예를 들어, CS 챗봇을 도입하고자 하는 회사는 가지고 있는 FAQ 문서와 고객 대응 정책 문서들, 그리고 과거의 문의 및 답변 내용을 바탕으로 데이터셋을 만들어서 ChatGPT에게 학습시키는 방식을 생각할 수 있겠습니다. 쉽게 떠올릴 수 있는 방식이지만, 비용이 많이 들고 유연성이 떨어진다는 큰 단점이 있습니다.

한계점 1. 높은 호출 및 학습 비용

상용 LLM을 그대로 사용하는 것도 비용이 많이 들지만 우리 회사 데이터에 LLM을 Fine-tuning 하고, Fine-tuning이 완료된 모델을 사용하는 것은 더욱 비쌉니다. 여기에 모델을 학습시키기 위해 정제된 데이터셋(Annotated dataset)을 제작하는 비용과 학습 비용까지 고려하면 훨씬 더 많은 비용이 발생합니다.

아래 그림은 OpenAI 홈페이지에서 발췌해온 ‘Fine-tuning models’의 비용인데요. 가장 작은 모델인 Ada부터 가장 큰 모델인 Davinci까지, 1) 각 모델을 Fine-tuning 할 때의 학습 비용(Training)과, 2) Fine-tuning이 완료된 모델을 활용할 때의 추론 비용(Usage), 이렇게 두 단계로 과금이 됩니다.

ChatGPT 3.5(gpt-3.5-turbo) 모델의 추론 비용(Usage)이 $0.002/1K token인 것에 비해 같은 3.5 시리즈 모델인 Davinci Fine-tuning의 추론 비용이 60배 비싸다는 것을 확인할 수 있습니다. 즉, 내 데이터에 Fine-tuning 된 Davinci 모델을 사용하는 경우, 호출할 때마다 기본 LLM 대비 60배에 달하는 비용이 발생합니다.

한계점 2. 업데이트 되는 지식에 대한 유연성 부족

Fine-tuning 방식의 또 다른 단점은 외부 지식이 수정되거나 새롭게 추가될 때마다 매번 학습 데이터를 제작하고, 다시 학습을 시켜야 한다는 것입니다. 참고해야 하는 외부 지식이 업데이트 되었다고 했을 때, 기존에 학습된 데이터 중 특정 정보만을 변경하거나 업데이트 하기 어렵습니다. 또한, 새로운 외부 지식을 추가적으로 학습시키기 위해서는 해당 지식을 정제된 데이터셋으로 가공하는 과정을 또 거쳐야 합니다.

그때마다 데이터 어노테이션 비용과 학습(Training) 비용이 발생하고, 무엇보다도 평균 6개월의 시간을 투자해야 합니다. 예를 들어, CS 챗봇에 변경된 우리 회사 고객관리 정책과 업데이트 된 FAQ를 반영하기 위해서는 신규 정책과 FAQ 문서를 다시 LLM을 Fine-tuning 시켜야 하는 번거로움이 있습니다.

2) 프롬프트 엔지니어링 (Prompt Engineering)

프롬프트 엔지니어링이란, LLM이 수행해야 하는 과제를 자연어로 입력하여, 원하는 use case에 적합한 결과(output)를 반환하게 하는 방식입니다. 이 방식을 활용하면 아래 그림과 같이 프롬프트를 통해 우리 회사의 정책과 특성에 맞는 답변을 생성할 수 있습니다. 앞서 LLM이 ‘인증 메일’에 대한 일반적인 답변을 반환한 것과 달리, 아래 예시에서는 우리 회사의 인증 메일 정책에 대한 답변을 반환합니다.

CS 챗봇을 도입하고 싶은 회사라면 반드시 필요한 맥락이겠죠. 고객이 챗봇에게 원하는 것은 인증 메일에 대한 일반적인 내용이 아닌, 우리 제품/서비스를 이용할 때 인증 메일을 어떻게 받을 수 있는지에 대한 정보일테니까요.

프롬프트 엔지니어링은 참고해야 하는 문서의 양이 적을 때 Fine-tuning 방식보다 저렴하게 목적을 달성할 수 있다는 장점이 있습니다. 하지만 프롬프트 엔지니어링의 가장 큰 단점은 참고해야 하는 문서의 양이 많은 경우 매우 비효율적이라는 것입니다.

한계점 1. 모델의 토큰 수 한계로 인해 한번에 최대 입력할 수 있는 문서의 길이 제한

프롬프트 엔지니어링으로 대량의 외부 지식을 입력하는 경우, 모델이 처리할 수 있는 최대 토큰 수를 초과할 수 있습니다. GPT-4와 같은 대부분의 트랜스포머 기반 모델들은 토큰 수 제한이 있기 때문입니다. 이 제한은 모델의 아키텍처와 사용 가능한 컴퓨팅 리소스에 따라 다른데요, GPT-4의 경우 적게는 8,192 토큰, 많게는 32,768 토큰까지 가능합니다.

한계점 2. 대량의 문서를 참고해서 답변하는 데 소요되는 높은 비용과 느린 응답속도

LLM에 입력할 수 있는 프롬프트 최대 길이에 맞춰서 여러 차례 호출하는 방식으로 필요한 문서를 모두 입력하는 방법도 생각할 수 있는데요. 이 경우 토큰 수에 비례하여 비용이 증가하는 것은 물론이고, 호출한 횟수만큼 답변 생성에 소요되는 시간이 증가합니다.

아래는 페이지 당 약 1,000자가 담긴 200페이지짜리 PDF 문서 안의 텍스트를 모두 프롬프트로 입력하는 경우를 가정한 비용 산정 예시입니다. 이 PDF를 참고해서 답변을 한다고 했을 때 호출 때마다 [260 + a]원이 발생한다고 볼 수 있습니다. 일반적인 AI API의 호출당 가격이 10원 대임을 감안할 때 매우 비싼 가격입니다.

이는 외부 지식에 해당하는 문서의 텍스트를 입력하는 비용일 뿐입니다. 실제로는 답변의 길이까지 고려해야 하지만 편의상 결과를 호출하는 비용은 반영하지 않았습니다. 답변을 받기 위한 길이까지 고려하면 문서로 입력할 수 있는 토큰 길이는 더 짧아야 합니다.

💡 Cost Example:
gpt-turbo-3.5에게 200페이지짜리 PDF 문서 안의 텍스트를 참고할 수 있게 프롬프트로 입력하는 경우

1 토큰 = 1 글자라고 가정

한 페이지에 담긴 텍스트의 토큰 수가 약 1,000 토큰이라고 가정

전체 문서 토큰 수 = 100,000 토큰

500 토큰 * 200페이지 = 100,000 토큰

100,000 토큰 호출 비용 = $0.2

100,000 토큰 * ($0.002/1K 토큰) = $0.2

문서 하나의 텍스트를 프롬프트로 입력하는 비용 = 약 260원

GPT3.5를 기준으로, API를 통해 답변을 받는데에 걸리는 시간은 약 10초입니다. GPT 3.5의 최대 허용 길이가 4,096 토큰일 때, 위 예시의 경우 50번의 호출이 필요하며, 이는 질문 하나에 대해 답변을 얻기까지 약 500초, 약 8분이 소요됨을 의미합니다.

Retrieval-augmented Generation

우리 회사 서비스에 AI 챗봇을 도입한다고 했을 때, 충족해야 하는 요건들의 예시는 아래와 같습니다:

서비스 사용자들이 챗봇에게 얻고 싶어하는 내용을 반환할 수 있어야 합니다.
그러기 위해서는 기존 대화 기록, 서비스 정책, 서비스 이용 방법 등, 우리 회사가 가진 외부 지식에서 사용자 질문에 도움이 되는 정보를 잘 참고해야 합니다.
참고해야 하는 외부 지식이 변경되거나 추가되어야 할 때 유연하게 업데이트 할 수 있어야 합니다.
응답 속도가 지나치게 느리지 않아야 합니다.
AI 챗봇을 도입하는 비용 대비 AI 챗봇을 통해 얻는 경제적 가치가 적절한 ROI(Return on Investment)를 달성할 수 있어야 합니다.

앞서 소개했던 Fine-tuning과 프롬프트 엔지니어링 방식으로는 이러한 요건들을 충족시키기 어렵습니다. LLM 단독으로는 질문에 답하기 위해 사전학습하지 않은 외부 지식에서 적절한 정보를 찾고 답변을 생성하는 데 어려움이 있기 때문인데요. 대량의 외부 지식에서 사용자의 질문에 대해 도움이 되는 정보를 찾는 역할을 수행하는 별도의 AI 모델이 있다면 이 문제가 해결됩니다. 이 모델을 Retriever 이라고 하고, 이 과정을 Retrieval 이라고 합니다.

Retriever 모델은 대량의 외부 지식에서 사용자의 질문에 도움이 되는 정보를 찾는 역할을 수행하고, LLM은 Retriever가 찾은 제한된 정보를 참고하여 사용자의 질문에 대한 답을 하는 역할을 수행하게 되면, 챗봇 사용자의 질문에 적합한 답변을 생성할 수 있습니다. 이를 Retrieval-augmented Generation 방식이라고 부르며 아래의 도식이 이 과정을 잘 표현하고 있습니다.

Retriever는 사용자의 질문에 대한 답변을 생성하기 전에, 외부 데이터 소스로부터 필요한 정보를 검색하고 추출할 수 있게 도와줍니다. 주로 많은 양의 정보나 데이터에서 특정 질문에 가장 적합한 답변을 찾는 목적으로 학습됩니다. 최근 ChatGPT Plus 사용자들에게 공개된 ChatGPT의 Plugin 중에서도 AskYourPDF, ChatWithPDF와 같이 Retriever 기능을 덧붙인 Plugin들이 등장하고 있습니다.

Retrieval은 크게 키워드 기반 검색(Sparse Retrieval)과 문맥 기반 검색(Dense Retrieval)으로 나눠서 볼 수 있습니다.

1. 키워드 기반 검색(Sparse Retrieval)

주어진 질문의 키워드가 정확히 포함된 정보를 찾는 방식입니다. 일반적으로 특정 문서/문단에서 자주 등장하는 단어를 키워드라고 정의합니다. 질문과 외부 데이터 소스에서 키워드, 즉 핵심단어를 잘 정의하는 것이 정확도에 큰 영향을 미칩니다.

이 방식은 질문에 포함된 키워드 만으로도 답변이 포함된 문서를 특정할 수 있을 때 잘 작동합니다.

앞서 등장한 ‘인증 메일’ 예시를 다시 가정해 보겠습니다. “인증 메일”이라는 단어를 정확하게 입력하면 검색 결과가 잘 나오지만, “회원가입이 안돼요”와 같이 키워드를 특정하기 어려운 서술형 질문이거나 답이 있는 문서에 키워드가 포함되지 않은 경우에는 원하는 검색 결과로 이어질 가능성이 낮습니다.

또한, 텍스트로 이미지나 동영상 등을 검색해야 하는 경우, 키워드 기반 검색으로 적절한 결과를 찾는데 어려움이 있습니다.

2. 문맥 기반 검색(Dense Retrieval)

Retriever 모델이 문장이나 질문의 의미를 기반으로 정답이 포함되어 있는 문서/문단을 찾기 때문에 키워드 검색보다 더 광범위한 질문에 대해 정확한 결과를 받을 수 있습니다. 키워드 검색으로는 어려운 서술형 질문에 대한 답변이 가능하고, 답이 있는 문서에 키워드가 없더라도 이를 찾을 수 있습니다. 또한, 표와 같이 일반적인 텍스트와 특성이 다른 형식에 대해서도 의미를 이해하여 검색이 가능하고, 텍스트 뿐만 아니라 이미지나 동영상 등의 서로 다른 modality 데이터 간의 검색도 가능합니다.

각각의 차이에 대해서는 이후 Tech Blog 포스트를 통해 더 자세히 설명하도록 하겠습니다.

Fine-Tuning vs. Prompt Engineering
vs. Retrieval-augmented Generation 장단점 비교

위에서 소개한 내용을 정리하면, LLM이 우리 서비스에 특화된 답변을 생성하기 위해서는 LLM이 사전학습 하지 못한 외부 지식(External Knowledge)을 잘 참고할 수 있어야 하며, 이를 구현하기 위한 방식으로 Fine-tuning과 프롬프트 엔지니어링이 자주 언급됩니다. 하지만 이 두 가지 방식이 가지고 있는 고유한 한계로 인해 Retriever모델이 필요합니다.

각 방식의 장단점을 비교하면 아래와 같습니다:

SoftlyAI의 Retrieval-augmented Generation

SoftlyAI는 기업들이 AI 전문성 없이도 운영하는 제품/서비스 use case에 특화된 AI 챗봇을 빠르고 유연하게 구현할 수 있도록, 고도의 Retrieval-augmented Generation 기능을 제공하는 3rd Party 솔루션을 제공하고 있습니다.

생성(Generation)을 동반하는 시스템에서 문맥 기반 검색(Dense Retrieval)은 더 우월한 성능을 보이지만 구현을 위해서는 높은 AI 전문성이 요구되기 때문에, 기업 내부적으로 직접 개발하는 경우 오랜 시간과 비용이 소요됩니다.

최근 채용이 어려운 AI 전문가로 구성된 팀을 꾸려야 하는 것은 물론이고, Retriever에 대한 심도 깊은 연구가 동반되어야 합니다.

SoftlyAI는 내부 개발을 통해 최근 공개된 Retrieval plugin과 제품들 대비 높은 성능을 달성하고 있습니다. 대부분 OpenAI의 text-embedding-ada-002 기반으로, 벤치마크 지표상 53.3점 정도의 성능에 그친다고 합니다. 이렇듯 높은 성능을 달성할 수 있는 배경에 대해서는 추후 Tech Blog 포스트를 통해 더 자세히 설명 드리겠습니다.

SoftlyAI는 각 도메인에서 차별적 경쟁력을 가지고 있던 서비스들이 LLM으로 인한 AI 패러다임 변화를 기회로 삼았을 때 많은 부가가치가 창출될 것이라 바라보고 있는데요. 빠른 기능 출시를 통해 유효성을 린(lean)하게 테스트 해봐야 하는 스타트업 특성상, 특정 기능을 개발하는 데 긴 시간과 큰 비용이 소요된다는 것은 큰 리스크입니다. 무엇보다 제품 출시의 적시성(Time-to-Market)을 회사 전략에 맞게 통제하기 어렵습니다.

이러한 어려움을 겪고 있는 기업들을 위해 빠르고 유연하게 테스트 할 수 있는 시스템을 제공하고 있는 만큼, SoftlyAI와의 파트너십을 통해 LLM의 잠재력을 실험해보고 싶은 기업들은 언제든지 연락 주세요.