더 빠르고 더 정확한 RAG 구축 방법
1. 생성형 AI와 LLM 활용의 한계
모두들 아시다시피 불과 1~2년 사이에 OpenAI의 ChatGPT, 구글의 Gemini, 메타의 LLaMa 등 여러 LLM을 기반으로 하는 생성형 AI가 대중화 되었습니다. 자연스럽게 기업들도 생성형 AI를 비즈니스에 도입하여 생산성을 높이려는 시도들을 많이 하고 있습니다.
생성형 AI는 굉장히 큰 규모의 데이터로 사전에 충분히 학습된 LLM을 기반으로 동작을 하는데, 이게 범용적이고 일반적인 질문들에는 비교적 정확한 답변을 합니다. 그러나 특정 도메인의 전문 지식이나 별도의 데이터를 필요로 하는 질문을 하면 생성 결과의 출처도 알 수 없는 완전히 엉뚱하거나 잘못된 답변을 하게 됩니다.
바로 이것이 거짓 정보를 사실인 것처럼 출력하는 환각(Hallucination) 현상인데 일반적인 생성형 AI 모델의 한계입니다.
비즈니스 의사 결정을 하는데 있어서 잘못된 정보를 기반으로 하면 절대 안되므로 기업에서 생성형 AI를 도입하는데 가장 큰 걸림돌이 되고 있습니다.
이 문제를 해결하기 위해 일반적으로 LLM에 특정한 지시를 전달하는 프롬프트 엔지니어링을 하거나, 모델의 매개변수를 조정하는 파인튜닝을 적용합니다. 그런데 프롬프트 엔지니어링은 프롬프트 입력 제한 등으로 인해 개선 할 수 있는 성능에 한계가 있고, 파인튜닝은 기술적인 복잡함과 고성능 컴퓨팅 파워를 필요로 하기 때문에 비용이 많이 발생하는 문제가 있습니다.
2. 기업의 내부 데이터를 대상으로 하는 LLM+RAG 서비스 수요 증가
검색 증강 생성(RAG)은 바로 이러한 생성형 AI의 한계를 극복하기 위한 여러가지 방법중에 하나입니다. 간단하게 말하면 정보를 검색하는 부분(이후 Retriever라고 하겠습니다.)과 답변을 생성하는 부분을 결합하여 최종 결과물의 정확성을 높이는 방법입니다. 기업의 데이터를 벡터로 변환하여 DB에 저장하고, 사용자의 질문이 입력되면 쿼리로 변환하여 해당 쿼리와 유사한 데이터를 DB에서 검색하여 답변의 생성에 이용합니다.
이러한 RAG의 장점은 리트리버만 추가하면 모델의 추가 학습 없이도 빠르고 저렴하게 사용자 데이터를 반영할 수 있다는 점입니다. 그리고 임베딩 데이터는 인덱싱되어 관리되므로 답변의 생성에 어떤 데이터를 참조하였는지 알 수 있고 더 나아가 환각 여부도 판단할 수 있습니다.
이렇게 RAG를 사용하게 되면 LLM만 사용했을때 보다 답변의 정확성이 크게 향상되므로, 최근 기업들이 내부 데이터를 대상으로 하는 질의 응답 시스템을 RAG로 구축하는 사례가 많아지고 있습니다.
3. RAG 구축 프로세스
데이터 소스 연결에서부터 답변을 받기까지 RAG 를 구축하는 전체 순서는 아래 그림과 같습니다.
각 단계별로 LangChain에서 제공하는 도구를 사용하거나 아니면 별도로 외부의 다양한 도구들을 선택하여 사용할 수도 있습니다.
문서를 임베딩 하는 모델로 무엇을 사용할 것인지, 리트리버를 구현할때 어떤 검색 기법을 사용할 것인지 등은 모두 여러가지 옵션이 있으며, 프롬프트 엔지니어링과 함께 RAG의 정확도를 개선하는데 영향을 미치게됩니다.
4. 고품질 RAG 적용 사례
최근 스마트마인드가 고객사에 ThanoSQL을 기반으로 RAG를 적용한 사례를 살펴보겠습니다.
고객사 내부에 축적되어 있는 비즈니스 문서를 대상으로 하는 RAG 챗봇을 구축하는 프로젝트 였는데, 어떻게 하면 기존 방식의 RAG 챗봇보다 더 정확하고 더 빠른 답을 얻을 수 있을까요?
위에서 언급한 RAG 구축 단계의 일반적인 내용들은 인터넷상에 참고할만한 좋은 자료들이 많기 때문에 여기서 자세히 언급하지는 않겠습니다.
본 게시글에서는 실제로 기업에 적용할때 답변의 품질을 높이기 위해, 특히 ‘검색’ 단계에서 속도와 정확성을 높이기 위해 무엇을 어떻게 했는지를 말씀드리겠습니다.
대부분의 경우 기업에서 RAG 기반의 챗봇을 도입한다고 할 때 RAG의 대상이 되는 데이터는 기업이 보유하고 있는 ‘문서’를 의미합니다.
하지만 모든 문서가 동등한 것이 아니라 여러 측면에서 차이가 있습니다. 대표적으로, (1) 문서가 담고 있는 내용(예, 특정 업무) (2) 문서에 대한 접근 권한(예, 대외비 또는 특정 부서만 접근 허용 등) (3) 공개 가능 여부 (예, 저작권 문제로 자료를 드러내면 안되는 경우) 등에서 차이가 있으므로 이러한 정보를 문서에 메타데이터로 덧붙여야 합니다.
예를 들어 ‘S/W 개발 방법론’이라는 문서가 있다면 이 문서는 개발(문서 주제)에 관련된 것이고 개발 조직에 속한 사람들만 열람(접근 권한) 가능하며 대외비(공개여부) 라는 메타데이터를 추가하게 됩니다. 또 다른 예로 ‘회사생활 가이드’라는 문서는 주제가 회사 일반이고 전체 직원 누구나 볼 수 있으며 공개도 가능하다는 메타데이터를 추가할 수 있습니다.
모든 문서에 다 별도의 메타데이터를 붙이는 것도 가능하지만 그렇게 되면 관리의 부담이 커지므로 같은 메타데이터를 가진 문서들끼리 모아서 그룹화하여 ‘컬렉션’이라고 이름을 붙였습니다. 그리고 메타데이터는 이 컬렉션에 부여하는 방식을 사용했는데 그렇게 되면 특정 컬렉션 내의 문서들은 모두 동일한 메타데이터를 가지게 됩니다.
한편 기업에서 도입하는 챗봇의 용도도 여러가지가 있을 수 있습니다. 특정 부서 또는 특정 업무 담당자들을 위한 챗봇(예, IT 보안 부서의 보안 모니터링 담당자를 위한 챗봇)이 있을 수 있고, 전체 임직원을 대상으로 한 특정 분야 챗봇(예, 회사 복지 업무 지원 챗봇)도 있을 수 있습니다. 이렇게 다양한 챗봇 활용 상황을 ThanoSQL에서는 ‘시나리오’라고 부릅니다. 각 시나리오마다 필요로 하는 RAG 자료가 다르므로 앞에서 정의한 문서의 묶음인 컬렉션을 시나리오와 잘 매핑한다면 리트리버가 불필요한 데이터까지 모두 검색하는 시간과 비용을 아낄수 있고, 꼭 필요한 자료만을 활용하므로 답변의 정확도 역시 높일 수 있습니다.
예를 들어 법무 담당자가 특정 프로젝트의 하도급 계약 내용과 관련된 질의를 한다면 챗봇은 수행 프로젝트 컬렉션과 법령/규정 관련 컬렉션을 선택하여 해당 컬렉션들 내에서만 검색을 수행하고 그 결과를 가지고 답변을 생성하게 됩니다. 즉 관련이 없는 컬렉션은 검색하지 않으므로 거짓 정보를 생성하지 않게될 뿐만 아니라 응답시간도 짧아지게 됩니다.
5. 마치며
기업이 보유한 문서의 종류와 성격 그리고 적용할 시나리오의 다양성 등에 따라 위에서 언급한 세가지 메타데이터 이외에 다른 메타데이터가 추가로 필요할 수도 있습니다. 컬렉션 구성을 위한 이러한 메타데이터 태깅은 번거로울 수 있지만 일정 부분은 AI로 자동화가 가능하며 RAG 검색의 속도와 정확성을 높이기 위해서는 필요한 과정이라고 할 수 있습니다.
이처럼 ThanoSQL을 이용하여 컬렉션과 시나리오를 매핑하는 방식으로 RAG를 구현한다면 다양한 분야에서 고품질의 서비스를 신속하게 제공할 수 있습니다.
KR 
EN