기업폐쇄망에서의 Private LLM 기반 Agentic RAG 구축 - 2편

 Agentic Workflow

1편에서 전통적 RAG 의 제한적 요소들에 대해 언급하였는데 이 중 의사결정, 동적 프롬프트 조정 그리고 외부 tool 접근 등은 AI Agent 기술의 등장과 더불어 보다 진보된 RAG 로서  그 면모를 새롭게 갖추게 되었다. 우선 그럼 Agent 라는 것이 무엇인가를 살펴볼 필요가 있다. 아래 그림 5 는 Agentic workflow 가 이전 zero shot 방식의 workflow 와 어떻게 다른지를 직관적으로 설명한다. 

아래 그림 왼쪽의 워크플로우는 어떤 주제에 대한 에세이를 작성하는데 있어서 시작부터 끝까지 한번에 쉼없이 작성하는 워크플로우를 나타낸다. 전통적 RAG 의 워크플로우라고 할 수 있겠다. 반면에 오른쪽 Agentic workflow 는 우리 사람들이 통상 하듯이 주제에 대해 에세이 개요를 먼저 생각해보고 초안을 작성하고 생각한 다음, 변경이나 조사가 필요한 부분을 조사한 후 변경하는 형태의 생각과 수정을 반복하는 과정을 거친다. Think Fast and Slow 의 저자 다니얼 커너먼은 이를 system 1 과 system 2 로 설명한다. 즉 우리가 10X 12 와 같은 곱셈은 직관적으로 120 이라고 답하는 system1 과 같은 사고라면, 240X126 과 같은 곱셈은 가만 있어 보자 하고 생각하면서 좀 더 시간과 두뇌를 더 쓰면서 답변하는 system 2 라는 사고 과정이라는 것이다. 이렇게 LLM 이 좀 더 숙고하고 변경을 거치는 워크플로우는 따라서 AGI 에 가까워지는 보다 고도화된 지능을 갖는 과정이라고도 할 수 있다. 

<그림 5. Agentic Workflow>

Agentic RAG

그러면 Agentic RAG 는 무엇일까? 기존 RAG 기능에 더해서 아래 그림 6과 같은 4가지 예로 보여지는 기능을 수행할 수 있는 RAG 를 뜻한다. 첫째, 기존 RAG 가 질문에 의미론적으로 유사한 문맥에 근거한 답변만을 제공하는 기능에서 제공하지 못했던 요약이나 비교, 계획등의 기능을 실현하는 것

둘째, 보다 중의적이고 복잡한 질문을 agent 의 회고(reflection)를 통하여 문장을 분석하고 보다 지능적인 답변을 제고하는 부분

셋째, 지식기반중에 정형 SQL 데이터를 보유한 경우에 자연어 질문으로부터 정형데이터의 접근 필요성을 감지하고 자연어 질문을 SQL 형태의 코드로 변환하여 SQL 데이터베이스를 검색하여 답변을 제공

넷째, function calling 기능이 부여된 LLM 을 통하여 web search 같은 외부 tool 을 통한 외부정보 검색 등을 제공하는 것을 의미한다.

<그림 6. Agentic RAG 예>

Spotify 에서 상위 5위까지의 유행곡

아래 그림 7은 이러한 tool을 통한 외부 정보 검색의 예를 보여준다. 1)에서 들어온 질문이 외부 tool 을 사용하여 답변해야 하는지가 결정되면 Agent 가 지원되는 LLM 을 통하여 2)와 같이 LLM 이  어떤 외부 tool을 자동선택(이 경우 web search tool) 하여 웹접근용 코드를 작성(실행)하고 3)번과 같이 웹검색에 전달될 tool 의 매개변수를 예측하여, 4)에서 5개 음악 곡의 곡명과 가수명 랭킹을 추출하여 5)번에 agent LLM 을 거쳐 6)번 LLM 을 통한 응답하는 흐름이다. 

<그림 7.  tool 을 통한 외부 검색 예>

예: tool 을 통한 외부 정보 검색 

아래 그림 8은 Llama 3.1 70B 함수 호출 기능을 사용하여 "스포티파이에서 상위5위까지의 유행 곡을 알려줘?" 라는 질문에 대해 내부적으로 함수 호출의 형식과 매개변수표시등의 프롬프트 방식의 예를 보여준다.

Llama 3.1 은 웹서치 기능을 제공하는 brave_search 함수, 계산 기능을 제공하는 wolfram_alpha 와 파이선 코딩을 지원하는 ipython 함수를 내장하고 있다. 이번 예 에서는 brave_search 와 ipython 함수가 선택되어 사용되었고 내부 매개변수는 5개 곡 곡명, 가수명 랭킹 등이 내부적으로 LLM 함수 호출에서 자동 예측되었다.

<그림 8. Llama 3.1 70B 함수 호출 예>

Behind the Scene

아래 그림 9는 그림 8 의 함수호출에서 내부적으로 수행되는 코드를 보여준다. 윗쪽 화살표에 보여지는 시스템 프롬프트에 담긴 내용은 ipython 환경이고 brave_search 라는 웹검색 도구와, wolfram_alpha 라는 계산기 도구들이 있으며 tool instruction 은 언제나 파이선 코드를 실행하고 실시간 정보를 탐색 시 만약 관련 함수가 있으면 사용하고 없으면 brave_search 을 사용하도록 되어있다. 아래 화살표는 agent 가 생성한 내부적으로 수행된 코드를 보여준다. spotify 를 import 하고 client id 를 가지고 spotify 계정의 토큰을 획득하며 items['name'] 과 items['artists'] 을 limit=5 로 국한하여 검색함을 알 수 있다. 

<그림 9. Behind the scene>

Vector Index vs Summary Index

아래 그림 10은 전통적 RAG 의 vector index 와 더불어 요약을 담은 summary index 를 통하여 전통적 RAG에서 구현할 수 없었던 문서 요약을 수행하는 예를 보여준다. 질문이 주어졌을 때 Router 를 통하여 전통적 질의 응답에 관련된 경우인지 요약을 필요로 하는 경우인지가 판별되고 요약이라고 판별될 경우에 오른쪽 경로를 타고 Summary 담당 query engine 이 summary index 를 통하여 요약을 검색한다.  이러한 과정에서 LLM Agent 가  필요한 함수와 연관되는 매개변수 역시 자동으로 유추한다.

<그림 10. Vector vs Summary Index>

Retrieving using Vector & Summary Tool

아래 그림 11은 이러한 vector index 와 summary index 라는 2개의 인덱스가 있는 상태에서 질문이 들어왔을 때 summary tool 과 vector tool 중에 어떠한 것을 사용할지를 LLM 의 agent 기능이 어떤 도구와 매개변수를 명시하여 사용할지를 지능적으로 유추하는 예를 보여준다. summary_tool 은 query_engine 으로 summary_query_engine 을 사용할 것을 함수에 명시적으로 선언하고 description 에 "llmissue_spri.pdf 와 관련된 요약에 대한 질문에 사용됨." 이라는 placeholder 를 선언해준다. agent tool 에서 함수는 전통적 파이선 함수와 다른 점은 LLM 이 이 description placeholder 내용을 함수 수행에 활용한다는 점이 차이점이다. 

아래 두번째 주피터 노트북 셀에서 ReActAgent.from_tools 라는 REACT agent 구성을 선언하였다. tool 의 매개변수로 [vector_tool, summary_tool], lllm 을 명시하였고 결국 REACT agent 가 이 둘 중에 질문의 내용을 보고 어떤 함수와 매개변수를 명시할지를 결정한다. 

아래에 response=agent.chat("ChatGPT 기술의 차이점은 요약은?") 이라는 질문에대해 하단에 Thought, Action, Action Input, Observation, Thought 로 진행되는 절차로 reasoning 과 action 이 반복 됨을 확인할 수 있고 마지막으로 Answer 를 출력하는 것을 보여준다.

<그림 11. Vector & Summary Tool 을 이용한 검색>

ReACT: Reasoning + Acting with LLM

앞에서 설명한 ReAct Agent 호출은 아래 그림 12 에 표시된 ReAcT 논문 에 기반한 이론을 기초로한다. 2023년 3월에 구글 브레인과 프린스턴대학교에서 발표된 논문을 요약하면, 이전까지는 Chain of thought 로 대별되는 Reason only 와,  WebGPT 와 같은 행동을 취한 다음에 결과를 관측하는 Act only 가 별도로 분리되어 있었는데, 논문에 의하면 이러한 Act-Observation 같은 Reason only 프롬프트 방식이나, Act-Observation 같은 Act only 프롬프트 방식으로 풀지 못하는 문제를 앞의 그림 11에서 나타난 Thought-Act-Observation 이 순환되는 형태의 프롬프트가 응답을 도출해내며 보다 높은 지능을 보여 준다는 것이다. 이를 위하여 이러한 Thought-Act-Observation 의 절차에 충실한 few-shot 형태의 프롬프트 template를 통하거나 langchain 같은 프레임워크에서는 이러한 few-shot 형태에서 보다 표준화된 template 를 사용하여 ReAcT Agent 를 구현한다.

<그림 12. ReAcT>

Text to SQL with ReAcT Agent 

Agent 를 사용하여 기존 RAG 에서 수행할 수 없었던 SQL 데이터베이스 정보 검색 수행을 할 수 있다. 아래 그림 13은 11개의 테이블 스키마를 보유한 SQLITE Tutorial 의 음원 판매 정보 관련 데이터베이스들을 예를 들어 설명한다.

<그림 13. 샘플 SQL DB>

Agentic RAG Flow: 앨범판매에 어느 국가가 가장 많은 돈을 지출?

아래 그림 14는 "국가별 총 판매액을 나열하세요. 어느 국가의 고객이 가장 많은 돈을 지불했나요?" 라는 자연어 형식의 질문에 대하여 ReAcT 를 agent 를 활용하여 SQL Agent 가 선택되고 flow 가 진행되는 것을 보여준다. 

1)에서 주어진 질문이 SQL Agent 를 사용해하는가 를 판별하고 

2)에서 Agent 를 통해 테이블 schema 를 보고 관련 query 처리 여부르 판단하는 SQL Query 를 작성하도록 생성하며, 만약 SQL 처리가 맞다면 

3)에서 schema 들로부터 agent 가 판별한 'customer' 와 'invoice' 라는 매개변수를 예측한다.

4)에서 질문에 답을 하기위해 'customer' 와 'invoice'를 join 한 SQL 문을 작성한다. 결코 쉽지 않는 SQL 구문이다. 

5)에서 query 를 실행하여 국가별 전체 매출을 순서대로 출력하여 6) 과 7)을 거쳐 응답을 리턴한다.

<그림 14. text-to-SQL 예>

ReAcT Agent & ChatOllama

아래 그림 15는  llama3.1 70B 모델을 Ollama 를 사용하여 chat 형태로 구현한 예로 첫번째 cell 에서는 Langchain 프레임워크를 사용한 AgentType.ZERO_SHOT_REACT_DESCRIPTION 을 사용하였다. 그 아래로 Entering new SQL Agent Executor chain... 이라는 SQL Agent 를 자동 선택한 내용이 보이고 이어서 Thought-Action-Action Input-Observation 등이 계속 반복되며 진행되어 sql_db_list_tables 를 검색하기 위한 SQL 코드가 작성되고, 그 다음 sql_db_schema를 검색하는 진행절차가 보인다. 

verbose=True 로 설정하여 주피터노트북에 표시되는 내부 실행 내용은 무척 길어 Action 부분만 캡쳐하여 표시하였다. 

맨 마지막에 Final Answer 로 미국의 고객이 가장 많은 돈을 지불했으며, 총 판매액은 523.86 입니다 라는 응답을 보여준다. 내부적으로 생성되는 SQL 코드는 쉽지 않은 자연어 질문에 대해 reason-act-observation 이라는 과정을 통해 정답을 찾기위한 agent 의 자체 학습, 목표 설정 그리고 동적 프롬프트 조정 능력을 보여준다. 

정형데이터 검색에 초기의 접근법을 보여준 것으로 보이고 지능적인 답변을 위해 소요되는 컴퓨팅 파워와 시간등을 감안하면 실제 정형데이터 검색에 얼마나 프로덕션 수준에 접근할 수 있을지 그 귀추가 주목된다. 아울러 생성된 SQL 코드의 실시간 검증이라는 부분이 어떻게 해결될지도 생각해볼 부분이다.

<그림 15. ChatOllama 로 구현한 Text-to-SQL>

결언

눈부시게 발전하는 OpenAI 와 같은 폐쇄형의 선두 기술들을 오픈소스 프레임워크등을 통해 폐쇄형의 온프레미스 환경에서 구현하는 것은 여러면에서 도전적이다. 오픈소스 진영이 폐쇄형 선두주자들과 어깨를 나란히 하는 시점이 올것이라는 믿음으로 이제 Agent 라는 새로운 지평의 초입에 서있다. 

전통적 RAG 이 시간과 정확성에 중점을 두고 진화해 왔다면, 이제 Agentic RAG 이라는 명제는 각 산업의 보다 다양한 내부 업무흐름에 보다 고도화된 지능에 기반한 검색 요구를 대응하기위한 하나의 방안일 것이라는 것에는 이견이 없을 것 같다. 

ChatGPT 가 2023년 6월 function calling 이라는 기능을 발표하면서 촉발된 이 agent 기능이 RAG 에 접목되는 매우 초보적 수준의 개념 증명 같은 내용을 공유한 것 같다. 그러나 확실한 것은, agent 는 결국 모든 산업 프로세스에 중간 broker 들을 없애고 agent 가 직접 추론 유추해서 적절한 기능을 자동 수행한다는 점에서 그 성장성은 매우 크고 Agentic RAG 또한 많은 관심을 받을것으로 예상한다.

기업폐쇄망에서의 Private LLM 기반 Agentic RAG 구축 - 1편

AI Agent 트렌드 부상

 지난 12월11일 코엑스 그랜드볼륨에서 개최된 AI Summit Seoul 2024 에서 "기업폐쇄망에서의 Private LLM 기반 Agentic RAG 구축"이라는 주제로 발표를 하였다. 올해로 7년째 개최되는 AI Summit Seoul 2024는 12월10일~11일 양일간 개최된 유료 행사로 100만원에 육박하는 가격에도 매회 1,500명 참석자가 행사 조기에 등록이 마감되는 국내 최대 AI conference 중 하나다.  예상했던 것과 같이 AI Agent 가 트렌드로 부상함을 느낄 수 있었다.  발표했던 내용을 간추려 정리해본다.

Closed-source vs Open-weight models

아래 그림 1과 같이 2022년4월부터 2024년 7월까지 GPT, Claude, Gemini 등의 폐쇄형 소스 기반 모델의 성능향상(MMLU 5-shot)의 증가가 2023년 10월 기점으로 87% ~89%의 완만한 증가세를 보이는 반면 같은 기간 Qwen 1.5 72B, Llama 3.1 70B, 405B 등의 Open-weighted 모델의 급속하게 추격하고 있음을 확인할 수 있다. 무엇보다도 올해 Meta 사의 Llama 3.1 405B 을 개방형 weight 로 발표함으로써 OpenAI 사의 GPT-4o 와 비견되는 성능을 온프레미스 환경에서 실행할 수 있는 기회가 주어진 점이 오픈소스 진영에 의미하는 함의가 크다고 하겠다.

2023년 3월 스탠포드대학에서 GPT-3 를 이용한 self-instruct 생성으로 Llama-7B 모델을 파인튜닝한 Alpaca 모델 공개로부터 영감을 받아 시작된 Open-weight 모델을 통한 Private LLM 개발 여정은 그동안 Polyglot, Llama 2, Falcon, Mixtral 8x7B, Llama 3 8B, Llama 3.1 8B, 70B 그리고 405B 까지 나 역시 아래 그림 1과 같은 궤적을 쫓아왔고 어느새 50개가 넘는 파인튜닝 모델을 보유하게 되었다는 점에서 감개가 무량했다. 이 과정에서 RAG(검색증강생성)를 위한 임베딩 및 LLM 모델 파인튜닝용으로 사용될 instruction 생성 데이터세트에 사용되는 GPT-4 의 성능을 대치할 모델로 Llama 3.1 405B 모델이 Open-weight 모델로 발표되어 매우 흥분되었었고 기업내부 폐쇄형 환경에서 외부 API 접속 없이 RAG 를 완성할 수 있을 것 같다는 나의 가설이 현실화될 수 있다는 생각에 기뻤다. 2023년 3월부터 모든 것이 가설과 실행, 에러, 수정 그리고 확인의 쉽지 않은 과정이고 무모할 수 있는 도전이었는데 어쨌든 현재는 여기까지 왔다.

<그림 1. Closed-source vs Open-weight models>

Llama 3.3 70B beats GPT-4o, Llama 3.1 405B

행사에서 발표하기 5일 전인 12월7일 마침 Meta 사의 Llama 3.3 70B 의 발표가 있었다. 3.1의 405B의 성능을 3.3 버전에서 70B으로 비슷한 성능을 제공한다는 것이다. 그간 405B 을 사용하기위해 4비트 양자화 버전인 경우에도 최소 H100 4대 정도의 환경을 보유해야 하는 제약을 3.3 버전의 70B 모델은 4비트 양자화의 경우 H100 1대에서 운영(약 42GB 메모리 필요)할 수 있게 해준다는 것을 의미한다. 이는 합성데이터 생성은 물론, 앞으로 급부상할 AI Agent 에서 의미하는 바가 크다. Meta 의 허깅페이스 모델 카드에서 언급한 바와 같이, Llama 3.1 8B 로는 AI Agent 를 수행할 tool calling 에서 제약이 따라서 70B, 405B 을 사용하기를 추천하고 있다. 

 아래 그림 2는 Llama 3.3 70B 과 GPT-4o 등과의 성능 비교를 보여주고 있다. 초록색 네모칸과 같이 Multilingual MGSM 의 경우, Llama 3.3 70B 이 GPT-4o 보다 뛰어난 성능을 보여주어 한글 데이터처리에 이점이 있을 것으로 보이고, 빨간색 네모칸은 가격 면에서 GPT-4o 를 사용하는 비용의 1/25 의 가격으로 사용이 가능함을 보여주고 있다.

<그림 2. Llama 3.3 70B beats GPT-4o>

Basic RAG Flow

아래 그림 3은 일반적인 RAG(검색증강생성) 흐름을 보여준다. GPT-4 에다가 국내 기업의 데이터와 관련된 질문을 하면 수조개의 데이터로 사전학습된 내용을 기반으로 해서 응답을 하므로 웹상에 존재하지 않는 기업내부 데이터에 맞는 데이터보다는 그럴듯한 응답(할루시네이션)을 제공할 확률이 크다. 이러한 LLM 의 국내 비정형 데이터 검색이라는 측면에서 2024년 한해 RAG를 검토한 기업들이 많았고 결과도 어느정도 만족할 성과들이 있었다. 먼저 기업내부의 비정형 문서들(HWP, MSDOC, PDF 등)을 문자열 형태로 읽혀들인다. 

이때 2)번과 같이 문자열로 변환된 전체 문서를 일정크기(chunk)의 문서로 분할한다. 다음 1) 번과 같이, 임베딩 모델을 사용하여 분할된 문서를 3)번과 같이 벡터로 변환한다. 예를 들어, 700 token 크기로 문서를 분할했다면, 700 토큰에 대응하는 벡터 내용들이 쭉 4)번의 vector DB 에 저장된다. 

5)번에 dataset 은 2)번의 분할된 문서를 '참조' 문서로 하여 질문과 답변을 생성하는 합성데이터를 의미한다. 이렇게 만들어진 합성데이터는 1)번의 임베딩 모델과 6)번의 Private LLM 모두에 파인튜닝하여 base model 로 사용된 Llama 3.1 8B 이 학습하지못했던 기업데이터에 few-shot 학습할 기회를 제공한다. 이렇게 준비된 상황에서 질문이 들어오면 7)번과 같이 질문도 역시 임베딩 모델로 벡터화하여 8)번과 같이, 질문 벡터와 vector DB에 저장된 벡터들과 1:1 유사도검색을 통하여 9)번의 사전에 정의된 Top-K 즉 유사도 순서로 랭킹 몇 위까지 표시하는 것에 따라 벡터DB 로 부터 유사 문서를 추출한다. 

만약 top-K 가 2라면 2개의 의미(semantic)가 유사한 문장이 검색되어 온다. 이 2개의 참조 문헌에 9)번과 같이, Private LLM (예를 들면, 파인튜닝된 Llama 3.1 8B)이 프롬프트(질문내용)를 던져 응답을 생성한다.

<그림 3. Basic RAG Flow>

Challenges: Building RAG in Closed Network System

발표주제에서 의미하는 바와 같이, 기업 폐쇄망에서의 Agentic RAG 구축은  몇가지 도전적 요소를 내포한다. 첫째, 당연한 이야기지만 기업폐쇄망에서의 구현은 외부 API 와의 연결이 보장되지 않는 곳이다. 눈부신 속도로 발표되는 최신 SOTA 모델 적용에도 허깅페이스와 같은 모델 저장소를 사용하지 못한다. 이를 위해 우리는 치타라는 LLMOPs Model Repository 에 기업용 파인튜닝된 모델 set 를 저장하고 이로부터 Git/LFS 같은 형태로 허깅페이스와 같은 모델 로드를 시도한다. 

둘째, 임베딩모델과 LLM 모두를 대상으로 기업내부 정보를 파인튜닝하는데 필요한 instruction dataset 을 생성하는데 외부 GPT-4o 를 대체할 성능의 합성데이터 생성용 로컬 LLM 이 준비되어야 한다.

셋째, RAG 를 구성하는 LLM, Vector DB, 트랜스포머, bitsandbytes 와 같은 양자화, Langchain, LlamaIndex 와 같은 LLM 응용 프레임워크 등 가용 기술요소가 파이선이나 파이토치와 같은 환경상의 최적화가 필요하다. 마지막으로, 이 들간에 이음새없는 통합이 필요하다. 오픈소스를 통한 개발에는 버전간의 충돌로 인한 통합에 많은 정성이 들어가는 것이 사실이다.

기업내부망의 LLM/RAG를 위한 효과적인 파이프라인을 제공하는 LLMOps

이러한 폐쇄망에서의 도전적인 요소들에 대응하고자 LLM과 RAG 개발/운영 측면에서도 LLMOPs 로의 전환이 불가피하게 되었다. '치타'는 그간 고객들이 요구하는 폐쇄형 환경에서 많은 참조사례를 확보한 바 있는데 이를 기반으로 LLMOps 로의 확장이 신속하게 이루어졌다. 아래 그림 4는 '치타'의 LLMOps 라이프사이클 파이프라인 모습을 나타낸다. 특히 1) Data Management 기능에서 데이터셋관리와 어노테이션 관리 부분이 강화되었고, 2)번 모델 개발/훈련에서 직관적인 워크플로우 기능과 워크스페이스 기능이 3)번 모델 관리에서는 임베딩 모델과 LLM 모델 저장소가 특히 4) 모델 서빙에서는 엔디비아에 특화된 Tritron Server 추론 방식을 채택하였고, 5) 모니터링에서는 모델 성능 모니터링과 더불어 오토스케일링 기능을 제공하여 서빙에서 부하가 증가할 경우, 자동적으로 GPU 자원을 확장하는 기능을 제공한다.

<그림 4. 기업내부망의 LLMOps>

Limitations of Traditional RAG

RAG는 분명히 내부데이터 보안 문제 없이 AI 검색을 제공하는데 역할이 있다. 하지만 아래와 같은 이유들로 제한 사항이 있는 것 역시 사실이다, 

첫째, 질문에대한  의미에 유사한 정보를 제공하는 단방향의 솔루션이다. 즉 보다 검색해보고 싶은 탐색적 능력이 부족하다.

둘째, LLM 이 사용되고 있지만, 자체 학습, 목표 설정과 같은 의사결정이 결여되어 있다.

셋째, 프롬프트는 어느정도 주어진 프롬프트를 사용한다. 질문과 답변이 목적이기 때문에 그렇다. 새로운 정보에 적응해서 동적으로 프롬프트를 조정해서 LLM이 보유한 보다 지성적인 동적 프롬프트 조정능력을 활용할 순 없을까?

넷째, 웹검색이나 SW API 같은 외부 tool 에 접근이 불가하다.

- 기업폐쇄망에서의 Private LLM 기반 Agentic RAG 구축 - 2편에서 계속됩니다.