네 안녕하세요 올거나이즈 대표 이창수입니다 아 저 오늘은 RAG에 대해서 좀 이렇게 딥 다이브 하는 세션을 가져볼 건데요 어 일단 먼저

RAG에 대해서 들어봤고 뭔지 개념을 알고 있다 하시는 분 손을 한번 들어 보시겠어요 네 네 한 절반 정도 되시는

거 같습니다 RAG 직접 만들어 봤거나 아니면 RAG 평가를 해봤다 하시는 분 손을 한번 들어 보시겠어요 네 네 한 한 1 정도 되는

거 같습니다 네 그러면 거기에 맞춰서 네 진행을 하도록 하겠습니다 기본적으로 이제 아는 많이 알고 계시니까 그 검색 증강 생성의

이제 기초적인 내용은 잠깐 스킵을 하고 이게 계속 개념이 확장된다고 보시면 되겠습니다 이제 오늘 제가

에이전트 RAG 말씀 드릴 건데요 결국 지금 에이전트와 RAG 왜 결합할 수밖에 없는지에 대해서 제가 오늘 세션에서 말씀을 드릴 겁니다 데

그러려면 이라는 게 도대체 어디까지 되는 게 rag 있가 보통 지금 알고 계시는 rag 개념이 어 상당히

협소한 경우들이 많이 있습니다 그래서 이제 그거를 좀 이렇게 다 같이 그라운드를 다지는 의미에서 말씀을 드리면 llm이 모든 걸 알고 있을

수는 없어요 그죠 LM 학습되지 않은 거는 어쨌든 모르니까 뭐인 컨텍스트 러닝이라는게 있기도 하지만 학습되지

않은 것은 llm 모르기 때문에 llm 모든 것을 알 수는 없습니다 그럼 llm이 모르는 것을 llm 게 동적으로 잘 전달해 주는 기술

사용자가 말한 의도를 잘 파악해서 그때 필요한 l&m이 모르는 자료들을 그게 문서가 되었건 외부의 웹이

되었건 데이터베이스가 되었건 어떤 다른 서버의 API 통해서 가지고 오는게 되었건 llm 외부의 지식을

가장 잘 다이나믹하게 구성해서 유저 의도에 맞춰서 LLM에 피딩하고 아로 정의를 하시면 오늘 세션을 훨씬 더 잘 이해하실 수가

있을 것 같습니다 그래 예를 들어서 뭐 2024년 10월에 개정된 법령을 요약해서 알려 줘 인데 예를 들면 이 LLM 뭐 작년까지

밖에 트레이닝이 안 됐어요 올해 1월까지 밖에 트레이닝이 안 됐어 이 알 수가 없잖아요 자 그러면

2024년 10월에 개정된 법령의 내용을 저기 오른쪽에 보시는 바와 같이 뭐 무슨 법에 뭐 오조은네

생략되고 무슨 법에 오조 삭제됐고 뭐 이런 식으로 찾아서 다이나믹하게 LM 프론트에 넣어 주는 기술이 일단

기본적으로네 아라고 보시면은 되겠습니다 실제 저 법령이 저렇게 삭제되 진 않았고요 네 예제를 위해서

만들었습니다. 자, 그러면 제가 오늘 세 단계로 구분 말씀을 드릴 거예요. 첫 번째 나이브 RAG, 두 번째

어밴스드 RAG, 세 번째 에이전트 RAG. 이렇게 세 가지의 스텝으로 나눠서 말씀드리겠습니다. 제가 단언컨대 대부분의 사람들이 아시는 RAG는

나이브 RAG예요. 대부분의 RAG 업체들이 만들어져 있는 솔루션도 나이브 RAG이고, 대부분 회사 내부에 AI 팀에서 만드는 것도 다 나이브라고 보시면

됩니다. 그러면 시스템 만들고 나서 이제 보통 저희한테 이제 오시는 분들이 이렇게 물어보세요. RAG 다 만들었는데

생각보다 성능이 너무 안 나오는데요. 정확도가 너무 안 나오는데요. 문서가 한 열 개는 괜찮았는데 비슷한 문서 한

500개를 확 넣었더니 또 잘 안 나오는데요. 이 고민에 공감이 가시면 RAG 실제로 해 보신 분입니다. 그래서 나이브 RAG 기본적으로

RAG 컨셉을 그냥 그대로 구현한 거라고 보시면 돼요. 유저가 이제 뭔가 질문을 하죠. 쿼리가 있으면 이 쿼리를

임베딩을 통해서 벡터로 바꿉니다. 그리고 문서들이 이제 여러 가지가 있을 거고 이 문서들을 청킹 합니다. 또

청킹이 어떤 사이즈 청킹이 가장 좋냐 이것도 약간 분분하기 합니다. 저희가 여러 가지 다이나믹한 사이즈 청킹

테스트해 봤을 때 옳은 아이즈 내부에 저희가 봤던 가장 좋은 청킹은 페이지 단위로 청킹 하는 거긴 했어요. 청킹

하고 이렇게 잘라진 청크를 또 다 벡터로 바꾸죠. 네. 그 벡터로 바꾼 다음에 여기 이제 쿼리에 있던 그

벡터와 청크로 잘라진 벡터들에서 가장 네, 질문에 대한 답변이 될 만한 것들을 이제 뽑아냅니다. 그렇게 해서 이제 벡터로

계를 뽑아내고 이렇게 뽑아낸 게 벡터에 원래 텍스트들을 참고해서 프롬프트를 만들어내는 게 기본적인 겁니다. 이게 나이브 아이디어예요.

나이브 아레는 여러 번 말씀드렸지만 상에서는 쓸 수 없는 퀄리티가 나옵니다. 그냥 아, 가 어떻다는 거를

어, 그냥 튜토리얼 해봤다네. 그냥 블로그 튜토리얼 보면은 뭐 클라우드 블로그 만들고 하는 거 5분, 10분

15분이면 만들지만 그걸로 절대 상용을 할 수가 없잖아요. 네, 그렇게 보시면 되겠습니다. 이거는 그냥 튜토리

만들었다고 생각하시면 되겠습니다. 그럼 어스 레지는 일단 뭐가 다르냐? 기본적으로 상용에 생기는 크게 두

가지의 문제가 있어요. 자, 그러면 이 리라는 모델이 리그레이션이잖아요. 기본적으로 라는 모델이 이렇게 임베딩

한 거에서 가장 유사한 것들을 일단 뽑아냅니다. 뽑아내는데 얘도 모델이에요. 얘도 AI 모델이기 때문에 어떤 상황에서도

100% 나온다는 불가능합니다. AI 100% 없어요. 뭐 97% 예를 들어서 하더라도 어쨌든 3% 틀리는 거잖아요. 그럼 리트리버가 저기에서

틀린 거를 찾아 가지고 LM 피딩을 했어요. 그러면 GPT 할아버지가 와도 틀린 후보들을 피딩을 했기 때문에

답을 맞출 수가 없습니다. GPT 4의 그 다음 다음 다음 버전이 나와도 틀린 거를 리트리버가 뽑아 주면 답을

맞출 수가 없어요. 그리고 기본적으로에 들어가는 프롬프트는 할루시네이션 최소화해야 되기 때문에 어 네가 아는

대로 말하지 말고 컨텍스트에 주어진 대로 컨텍스트 기반에서만 답을 해. 컨텍스트에 없으면 모른다고 해야 해라는 게 되게 중요합니다. 기본적으로

저희는 B2B 프로이고 회사 안에서 쓰여지고 회사 안에 있는 문서와 데이터베이스, 회사 안에 있는 각종 서버들과 연동이 되기 때문에

혹시라도 틀린 정보를 그럴 듯하게 이제 직원에게 알려 줘서 직원이 그 틀린 정보를 가지고 고객에게 아이템을

상품, 원래는 예를 들면 뭐 이율이 3%인 상품 이율이 5%라고 가능합니다라고 틀리게 안내해서 가입을

했어요 이러면 뭐 소송이 되는 거잖아요. 그게 의료나 법률 같은 경우로 가면 훨씬 더 크리티컬해지는

거고 그렇기 때문에 할루시네이션 최소화하기 위해서는 프롬프트를 최대한 스트릭트하게 써서 컨텍스트에 없는

건에 대해서는 절대 모른다고 해야 돼. 너의 지식에 기반해서 답하면 안 돼라는 게 기본적으로 들어가는 프롬프트. 그 이외에도

그렇기 때문에 리트리버가 틀린 거 세 개를 내 줬다 그러면 아무리 LLM이 똑똑해도 맞출 수가 없어요 왜냐하면

그 프롬프트 잘 따르니까 자 그러면 상용에서 이런 일이 정말 빈번하게 일어나요 리트리버가 이렇게 해가지고

틀린 거를 뽑아서 LLM 피딩을 하는 거죠 그래서 답이 틀립니다 그래서 아 GPT-4를 했는데도 정확도가 안

나오네요라는 거는 대부분 리트리버의 문제인 경우 그 이럴 때 어떻게 해결을 하냐 근데 아직까지도 대부분의 회사들은 이걸

되게 전통적인 방식으로 해결합니다 리트리버가 틀리면 어떻게 해야 되냐 리트리버를 다시 파인튜닝 해야죠 다시

트레이닝 해야죠 리트리버 트레이닝하려면 어떻게 해야 되냐 또 데이터를 모아야죠 리트리버가 틀린 데이터를 또

모아서 리트를 또 학습시킵니다 그래서 어떤 일이 생기면 콜센터에 예를 들면 들어가 있어요 상담원들이 답변을

빨리빨리 하기 위해서를 넣었어요 근데 뭔가 나온 답변이 틀렸어요 자 그러면 상담원들

어 이게 틀리게 답변한 데이터들을 모아 주세요 그래야지 AI 엔지니어가 다시 학습해서 다시 배포할 수 있습니다 근데 상담원들은 AI

들어오는게 사실 귀찮은 분들이시죠 아 이게 본인이 원래 일하기도 바쁜데 그럼 그런 사람들한테 틀린

데이터를 모아서 건네주면 AI 모델을 다시 리트 학습시켜 가지고 테스트하고 배포하고 하는데도 밖에 몇 주가

걸립니다 간단한 거 하나 고치는데 몇 주씩 걸리니까 사실 AI 대한 신뢰도가 더 떨어진 결과가 생깁니다

그렇기 때문에 포스트 리트리버라고 하는 게 리트리버가 틀린 것을 어떻게 그 자리에서 고칠 수 있냐라는 겁니다

저기 리랭킹이라고 하는 거는 원래는 뭐 후보를 예를 들면 다섯 개를 뽑아서 그 컨텍스트에 다섯 개를

준다고 해 볼게요 이제 그러면 저거를 뭐 10개를 뽑은 다음에 이제 틀렸던 것들에 대한 거를 뭔가

사용자가 피드백을 줬다 그러면 거기 다시 또 벡터 유사도를 해 가지고 이거를 랭킹을 다시 올립니다

그 처음에는 틀렸더라도 두 번째부터는 이게 바로 반영되게 하는 게 포스트 리트리버 들어가는 테크닉 중에서 가장

중요한 겁니다 이게 포스트 리트리버이고요 저기 프리 리트리버를 보면 있는 거는 뭐냐면 보통 임베딩 하나

쓰시는데 이 실버 블레이드 만능 임베딩이 하는 거는 없어요 왜냐하면 회사마다 문서의 스타일이 되게 다르고 문서의

제목을 붙이는 스타일 조차 되게 달라요 어디는 되게 특이한 DM 시스템을 써서 뭔가 내가 저장을 하면 그 뒤에

고유한 아이디 같은 걸 막 붙입니다 의미를 알 수 없는 숫자가 이렇게 막 들어가 있으면 이 벡터들이 잘 못 찾아요 이 왜 임베딩을 하냐 임베딩이

하는 거는 텍스트가 되게 다른데 의미가 우리 도면에 되게 유사한데 이런 것들을 계속 사전 추가 안 하고 AI 잘 판단해서 할 수 있게

임베딩을 하는 건데 의미가 없는 텍스트들이 제목에 있다 본문에 엄청 많이 어떻게 들어가 있다라고 하면

임베딩은 쥐약이 되게 잘 못 찾습니다 그래서 저희가 실제로 보면 이 임베딩 하나 리트리브 하나로는 잘 좋은 결과

나오지 않고 이거를 되게 여러 가지를 섞어서 이 고객사의 문서 스타일에 맞게 우리 회사의 문서 스타일에 맞게

옵티마이징을 하는 게 중요합니다. 이런 옵티마이징, 그 여러 리트리버의 옵티마이징 기술이 프리라고 보시면

되겠습니다. 까지가 이제 어스 아이고요. 저희가 제일 많이 듣는 질문이 뭐냐면, 그 저희는 저희 자체

LLM을 가지고 있고, 이 LLM 위해서 이따 좀 보여 드리겠지만 뭐 이렇게 아가 있고, 그 각 직군별로 쓸 수 있는 LLM 앱들을 만들 수 있는 그

이제 빌더들이 있습니다. 그럼 저희가 저희 자체 모델을 가지고 고객사에 이제 저희 플랫폼까지 들어갈 때

거기서 제일 많이 물어보신 게 뭐냐면 저희는 뭐 마케팅 부서장, 그다음에 뭐 회계 부서장, 다음에 제품 부서장이

쓰는 문서나 이런 게 되게 다르니까 부서마다 LLM 파인 튜닝을 해야 되는데 부서마다 LLM 파인 튜닝을

어떻게 하면 제일 효과적일까요 이런 걸 많이 물어보세요 사실 고객사들이 언제 LLM 파인 튜닝 해야 되는지

언제 LLM 파인 튜닝 하지 않고 RAG만 써도 되는지에 대해서 사실 아직까지 대단히 헷갈려 하십니다

이거는 이 전체 구조를 보면 어느 정도 정해진 답이 있는 문제입니다 첫 번째 RAG가 필요한 경우는 여기 이 y 축을 보시면 외부 지식이 필요한 경우 외부

지식이 뭐냐 LLM 에 가르치지 않은 지식, LLM 가르치지 않은 지식이 필요하면 무조건 RAG를 하셔야

됩니다 이 여기 이제 횡축, 횡축에 모델 어댑테이션 필요한 경우 모델 어댑테이션 뭐냐 모델 어댑테이션 크게

두 가지예요. 첫 번째, LM이 이미 알고 있는 뭔가 지식이 우리랑 다를 때, 회사랑 다를 때 LM이 잘못된 지식을 알고 있을 때 그걸 수정하려면

모델 파인튜닝 해야 돼요. 두 번째, LM 패턴에는 어떤 텍스트의 스타일이 우리 회사가 대단히 다를 때

예를 들면 약관 문서. 약관 문서가 LM 트레이닝에 쓰여지긴 했지만 LM 트레이닝에 쓰여진 다른 텍스트 대비

엄청나게 적습니다. 그래서 우리 회사 스타일대로 보험약관을 만들어 내야 된다라고 하면 무조건 파인튜닝을

하셔야 돼요. 그래서 모든 도메인에서 사실 ARE와 파인튜닝 다 필요하지 않습니다. 예를 들면 양쪽 다 필요 없으면 그냥 프롬프트 엔지니어링만으로

다 해결이 돼요. 네, 그게 제일 이제 왼쪽에 밑에 있는 거고요. 프롬프트 엔지니어링이 해결이 되고 이제 그다음에 어 우리는

이제 특별히 LLM 가지고 있는 거에서 어댑테이션 할 필요는 없다. 그냥 우리 회사의 지식을 LLM 잘 알기만 하면 된다라고 하면 사실

그냥 대부분 해결이 됩니다. 이제 왼쪽이고요. 이제 금융이나 공공기관 같은 경우는 문서 스타일이 우리가

보는 스타일과 되게 다른 경우가 막 많이 있어요. 네 뭐 복잡하게 표가 많이 있는 경우도 많이 있고 그다음에

수식이 되게 많이 들어가야 되는 경우도 있고 보험 약관 같이 우리가 일반적으로 이제 모르는 문서들 아니

별 리사가 쓴 특허 문서들 이런 걸 다룬다라고 하면 RAG LLM 파인 튜닝을 다 하셔야 됩니다. 그래서 지금

저희가 이제 고객사들이 가장 많이 쓰시는 게 두 가지가 있는데요. 첫 번째는 제너레이티브 랜서가 있고 두

번째는 제너레이티브 AI가 있습니다. 제너레이티브 AI 같은 경우는 저희가 보면 크게 세 단계로 나눠서 봐요. 자

첫 번째, 모든 고객사가 시작은 다 이 스텝으로 합니다. HR 관련된 문서 한 다섯 개 열 개를 넣어 놓고 직원분들이 HR 관련된 문의를 하면

답을 주는 거죠. 자, 이때는 문서가 그냥 폴더 하나에 다 들어가 있다고 보시면 돼요. 그다음에 문서가 많지

않죠? 이런 거는 나이브 베이즈를 구현하시는 것만으로도 웬만큼의 성과를 보실 수가 있습니다. 뭐 한 80%

사용자와 가장 똑똑하게 소통하는 LLM만들기 - 에이전트 기반 RAG전략 | 올거나이즈 이창수

2023년, SK의 AI 기술은 어떤 미래를 그리고 있을까요?
최고의 기술 기업과 전문가들이 경험과 노하우를 나누는 자리에 여러분을 초대합니다.


SK AI SUMMIT 2024

이창수 대표의 RAG 딥 다이브 세션 시작

청중의 RAG 이해도 확인 (절반 정도 이해)

청중의 RAG 직접 경험 확인 (소수 경험)

기본 개념은 간략히 설명하고 확장된 개념 중심으로 진행

에이전트와 RAG 결합의 필요성 설명 예고

LLM의 지식 한계: 학습되지 않은 정보는 알 수 없음

LLM이 모르는 정보를 동적으로 제공하는 기술로서의 RAG 정의

외부 지식(문서, 웹, 데이터베이스 등)을 동적으로 가져와 LLM에 제공하는 과정 설명

2024년 10월 개정 법령 예시를 통한 RAG 설명

세 가지 RAG 유형 비교 (Naive, Advanced, Agent)

세 가지 유형(Naive RAG, Advanced RAG, Agent RAG)으로 설명 구분

대부분의 RAG가 Naive RAG임을 강조

Naive RAG의 성능 저하 문제점 제시 (문서 수 증가에 따른 정확도 감소)

Naive RAG의 기본 개념 및 구현 방식 설명 (임베딩, 청킹, 벡터 유사도 비교)

Naive RAG의 상용화 불가능성 지적

Advanced RAG: 상용화 문제 해결 방안

상용 RAG에서 발생하는 두 가지 주요 문제점 제시 (리트리버의 오류, 할루시네이션)

리트리버의 오류로 인한 LLM의 부정확한 답변 문제 설명

할루시네이션 최소화를 위한 프롬프트 작성 중요성 강조

B2B 환경에서의 정확성 중요성 강조 (오류로 인한 법적 문제 발생 가능성)

리트리버 오류 해결을 위한 기존 방식의 비효율성 지적 (재학습, 데이터 수집의 어려움)

Post-retriever와 Re-ranking 기법 소개

Pre-retriever와 다양한 임베딩 기법 활용의 중요성 강조

고객사 문서 스타일에 맞춘 옵티마이징 필요성 설명

자체 LLM과 다양한 LLM 앱 제공 설명

부서별 LLM 파인튜닝 필요성과 효과적인 방법에 대한 질문 소개

RAG와 LLM 파인튜닝 필요 여부 판단 기준 설명 (외부 지식 필요성, 모델 어댑테이션 필요성)

모든 도메인에서 RAG와 파인튜닝이 필요하지 않음을 강조 (프롬프트 엔지니어링으로 해결 가능한 경우)

금융/공공기관 등 특수 도메인에서는 RAG와 LLM 파인튜닝 모두 필요할 수 있음을 설명

Generative AI 활용 단계 및 Agent RAG 소개

Generative AI 활용 단계를 세 단계로 구분 (Naive, Advanced, Agent)

첫 번째 단계: 소량의 문서를 이용한 Naive RAG 활용 (HR 문서 예시)

두 번째 단계: 대량의 문서와 다양한 폴더를 이용한 Advanced RAG 또는 Agent RAG 활용

세 번째 단계: 5만 개 이상의 문서를 이용한 Agent RAG 활용

데이터베이스 연동을 통한 정보 검색 (SQL 쿼리 변환)

사용자의 반복적인 질문 수정에 대한 Agent RAG의 필요성 설명

Naive 및 Advanced RAG의 단방향(One-way) 인터랙션 한계 지적

다양한 소스(문서, 데이터베이스, API) 활용에 대한 요구 증가 설명

복잡한 질문에 대한 Agent RAG의 필요성 강조 (골프 보험 예시)

다양한 보험 종류와 문서의 차이점을 설명하며 Agent RAG의 중요성 강조

AI Agent의 정의 및 작동 방식 설명 (목표 설정, 플래닝, 실행, 결과 평가)

기업용 LLM 플랫폼 회사 소개 (모델, RAG, LLM 앱 제공)

글로벌 고객사 현황 소개 (300개 이상)

데모 영상 소개 (두 가지 섹션: 단일 소스, 다양한 소스 활용)

단일 소스 데모: 분납 방법 질문에 대한 답변 (보험 종류를 알아야 정확한 답변 가능)

다양한 소스 데모: 대출금 현황 질문과 환율 변환 (웹 검색 연동)