안녕, RAG? 구글이 드디어 쓸만한 것을 출시하다!

채널 아이콘
SullyOmar 구독자 2,830명

요약

영상은 구글의 최신 AI 모델인 Gemini 2.0 Flash의 등장을 알리며, 기존에 널리 쓰였던 RAG(정보 검색 보강 생성) 기법이 이제는 구식이 될 수 있음을 주장한다. 화자는 RAG의 기본 개념과 기존 기법의 한계를 설명하며, 새로운 대용량 토큰 처리와 병렬 처리 전략을 통해 훨씬 더 효율적인 데이터 처리 방법을 제시한다. 또한, 실제 사례(예: 대용량 Earnings Call transcript 처리)를 들어 왜 단순 임베딩과 청크화 방식이 한계가 있는지 상세히 논의한다. 마지막에는 AI 제품 개발자와 분석가들에게 간결하면서도 효과적인 방법을 사용할 것을 권장합니다.

주요 키워드

Gemini 2.0 Flash RAG 임베딩 토큰 한계 컨텍스트 윈도우 청크화 벡터 데이터베이스 병렬 처리 AI 모델 Hallucination

하이라이트

  • 🔑 구글의 Gemini 2.0 Flash 모델 출시와 가격 대비 성능의 우수함을 강조함.
  • ⚡️ RAG(검색 보강 생성) 기법의 기본 개념과 한계를 상세히 설명함.
  • 🌟 기존 방식인 문서 청크화와 임베딩 과정이 복잡하며, 대용량 데이터의 추론에는 부적합함을 지적함.
  • 🚀 병렬 처리를 활용해 여러 문서를 동시에 분석함으로써, AI 모델의 응답 정확도를 높이는 방법을 소개함.
  • 📌 향후 AI 제품 개발 및 분석 시 단순하지만 효과적인 접근법을 사용할 것을 권장함.

용어 설명

RAG

Retrieval Augmented Generation의 약어로, 외부 자료를 검색해 언어 모델의 답변에 보강하는 기법을 의미함.

임베딩(Embedding)

텍스트를 수치화하여 벡터로 변환하는 기법으로, 문서 간 유사도 측정에 사용됨.

벡터 데이터베이스

임베딩된 데이터를 저장 및 검색하는 시스템으로, 문서 청크의 유사도를 빠르게 찾기 위해 사용됨.

토큰 한계(Token Limit)

AI 모델이 한 번에 처리할 수 있는 텍스트의 최대 토큰 수를 의미하며, 과거에는 작았으나 최신 모델은 매우 큼.

컨텍스트 윈도우(Context Window)

모델이 한 번에 참고할 수 있는 텍스트 영역을 의미하며, Gemini 모델은 대용량 컨텍스트 윈도우를 제공함.

청크화(Chunking)

대용량 문서를 작고 의미 있는 단위로 분할하는 기법으로, 기존 RAG에서 주로 사용됨.

[00:00:00] 소개 및 배경

구글이 Gemini 2.0 Flash를 출시하며, 가격 대비 우수한 성능을 소개함. RAG 기법에 대한 논쟁의 시작점을 제시함.

[00:00] 구글이 Gemini 2.0 Flash를 출시했으며, 이는 현재 최고의 가성비 모델로 평가받고 있습니다.
[00:07] RAG의 필요성에 대한 포스팅으로 인한 오해를 해소하고, 새로운 AI 모델이 가져올 변화를 설명하겠다고 소개합니다.
[00:00:28] RAG 기법의 기본 개념

RAG(검색 보강 생성)의 정의 및 활용 방식을 설명함. 임베딩, 청크화, 벡터 데이터베이스 등 기법의 세부 메커니즘을 다룸.

[00:29] RAG(Retrieval Augmented Generation)의 기본 개념과 ChatGPT, Perplexity 등에서의 활용 사례를 설명합니다.
[01:04] 컨텍스트 윈도우의 개념과 2023년의 4,000 토큰 제한에 대해 설명합니다.
[01:26] 전통적인 RAG 시스템에서의 임베딩, 벡터 데이터베이스 저장, 청킹 과정을 상세히 설명합니다.
[02:12] Gemini 2.0의 100만-200만 토큰 처리 능력과 이전 모델과의 큰 차이점을 비교 설명합니다.
[02:43] Gemini 2.0의 성능이 크게 향상되어 이전 모델의 6페이지 분량에서 현재는 백만 개 이상의 토큰을 처리할 수 있으며, 높은 정확도를 유지합니다.
[02:55] Gemini의 최신 모델은 가장 낮은 환각(허구 정보 생성) 비율을 보여주며, 2023년 모델들과 비교했을 때 큰 발전이 있었습니다.
[00:03:12] 기존 RAG의 한계와 문제점

과거 4,000토큰 제한 등의 문제로 기존 RAG가 한계를 보였음을 지적함. 단편적 정보 청크화가 복잡한 추론에 부적합함을 설명함.

[03:12] 전통적인 RAG 방식(문서를 작은 청크로 나누는 방식)이 더 이상 필요하지 않으며, 20줄 정도의 간단한 코드로 PDF 링크만으로도 처리가 가능해졌습니다.
[03:56] 실적 보고서와 같은 긴 음성 통화 기록(약 5만 토큰)을 예로 들어, 기존의 청킹 방식에 대해 설명합니다.
[05:21] 현재 RAG의 주요 문제점은 청킹과 임베딩 과정에서 정보를 효과적으로 추론할 수 없다는 것입니다.
[05:43] 애널리스트가 전사본을 분석할 때 단순한 수치 검색보다는 복잡한 분석이 필요하다는 점을 설명합니다.
[06:15] 실적 전망이나 투자 가치와 같은 복잡한 질문에는 전체적인 문맥 이해가 필요함을 강조합니다.
[06:34] 전통적인 RAG 방식의 한계점을 설명하고, 단순한 청크 매칭으로는 복잡한 분석이 불가능함을 지적합니다.
[00:07:00] 병렬 처리 및 새로운 접근법

대용량 문서를 병렬로 처리하는 새로운 전략을 소개함. Gemini 모델의 대용량 컨텍스트 윈도우를 활용한 효과적인 분석법과 추천 방안을 제시함.

[07:02] Gemini의 강력한 추론 능력을 설명하며, 50,000 토큰을 처리하며 전체적인 맥락을 이해할 수 있다고 강조합니다.
[07:51] 구글 AI 스튜디오의 실용적인 활용법을 소개하고, 문서 분석에 있어 새로운 접근 방식을 제안합니다.
[08:16] 넓은 의미의 RAG는 여전히 유효하며, 특정 사용 사례에 대한 설명을 시작합니다.
[08:29] 대량의 문서(10만 개)를 처리할 때의 접근 방식에 대해 설명. 실적 발표, 기업 자료 등 다양한 문서가 있는 상황을 예시로 듦.
[08:55] 대량 문서 처리시 단순 검색 시스템을 활용하여 관련 문서를 먼저 찾는 것이 효율적임을 설명.
[09:25] 새로운 접근 방식으로 병렬 처리 기법 소개. 선별된 문서들을 Google Gemini에 개별적으로 보내는 방식 제안.
[10:00] 기존의 청킹 방식 대신 AI 모델의 저렴한 비용을 활용한 병렬 처리 방식의 장점 설명.
[11:05] 맵리듀스와 유사한 이 방식이 관련 정보를 효과적으로 필터링하고 처리하는 방법임을 정리.
[11:24] 전통적인 RAG 시스템의 한계점을 설명하며, 문서를 병렬로 처리하고 AI에 전달하는 새로운 접근 방식을 소개합니다.
[11:50] 구글의 새로운 모델은 비용이 저렴하면서도 환각 현상이 적고 정보 검색 능력이 뛰어나다는 장점이 있습니다.
[12:12] RAG 시스템 구축 시 단순하게 시작하고 필요할 때만 복잡성을 추가하는 것을 권장합니다.
[12:40] 전통적인 RAG의 한계를 지적하며, 모든 데이터를 종합적으로 분석하여 충분한 답변을 제공하기 어렵다는 점을 설명합니다.
[00:00] 구글이 최신 모델을 출시했는데요,
[00:01] Gemini 2.0 Flash입니다.
[00:03] 현재 사용할 수 있는 모델 중에서
[00:05] 가성비가 가장 좋습니다.
[00:07] 제가 RAG가 더 이상 필요하지 않을 수 있다고
[00:09] 포스팅을 했더니 많은 분들이
[00:11] 제 의도를 오해하시고 화를 내셨습니다.
[00:14] 이 영상에서는
[00:15] 제가 정확히 무슨 의미였는지 설명하고
[00:18] 전통적인 의미의 RAG가
[00:19] 왜 더 이상 필요하지 않다고 생각하는지,
[00:21] 이 새로운 AI 모델들이
[00:23] AI 제품 개발 방식을 어떻게 바꿀 수 있는지,
[00:25] 그리고 이것이
[00:26] 개발자나 AI 입문자들에게
[00:28] 어떤 의미인지 설명하겠습니다.
[00:29] 먼저 RAG에 대해 모르시는 분들을 위해
[00:32] 간단히 설명하겠습니다.
[00:33] RAG는 검색 증강 생성
[00:35] (Retrieval Augmented Generation)의 약자로
[00:38] ChatGPT 같은 LLM이
[00:42] 학습 데이터에 없는
[00:44] 정보를 가져올 수 있도록
[00:46] 도와주는 일반적인 기술입니다.
[00:48] Perplexity 같은 기업들이
[00:49] 웹 검색할 때 질문을 보강하거나
[00:52] ChatGPT에서
[00:54] 프로젝트에 파일을 추가할 때
[00:56] 이 기술이 사용됩니다.
[00:58] 이때 뒤에서 일어나는 중요한 개념이
[01:01] 컨텍스트 윈도우입니다.
[01:04] 컨텍스트 윈도우는
[01:06] AI가 처리할 수 있는
[01:08] 텍스트의 최대 양을 의미합니다.
[01:11] AI 시간으로는 엄청나게 긴 2년 전인
[01:14] 2023년에는 토큰 제한이 매우 작았습니다.
[01:17] 2023년 초를 보면
[01:19] 토큰 제한이 4,000개였습니다.
[01:23] 당시에는 RAG가 매우 중요했죠.
[01:26] 일반적인 기법으로
[01:28] 정보를 가져와서
[01:30] 임베딩을 만들고
[01:33] 벡터 데이터베이스에 저장했습니다.
[01:35] 대량의 텍스트나
[01:36] 파일, PDF가 있으면
[01:39] 청킹이라는 중요한 과정을 거쳤는데,
[01:41] 이는 텍스트를
[01:43] 작은 조각으로 나누는 것입니다.
[01:45] 대략 한 단락 정도의
[01:47] 크기로
[01:48] 256에서 512 토큰 정도입니다.
[01:52] 이 텍스트를 가져와서
[01:55] 임베딩으로 변환하고
[01:57] 벡터 데이터베이스에
[01:59] 저장했습니다. 사용자가
[02:01] 질문을 하면, 그 질문을 가지고
[02:04] 가장 관련성 있는
[02:06] 작은 정보 조각들을 찾아
[02:08] 언어 모델에 전달해
[02:10] 답변을 생성하도록 했습니다.
[02:12] 하지만 Gemini 2.0처럼
[02:15] 대규모 컨텍스트를 가진
[02:16] 모델은 100만, 200만 토큰을 처리할 수 있어서
[02:19] 모든 정보를 한 번에 제공하고
[02:21] 사용자가 답변을 얻을 수 있습니다.
[02:23] 이 차이를 이해하는 게 중요한데,
[02:25] 예전에는 4,000 토큰이었지만
[02:27] 지금은 토큰 제한이
[02:29] 매우 커졌습니다.
[02:31] Gemini는 100만 토큰을 처리할 수 있고
[02:34] 일부 모델은 200만 토큰까지
[02:36] 처리할 수 있습니다.
[02:38] 이 차트를 보시면
[02:40] GPT-3.5는 4,000 토큰이었는데
[02:43] 토큰은 약 6페이지 분량이었지만,
[02:45] 현재는 Gemini 2.0에
[02:48] 백만 개가 넘는 토큰을 입력할 수 있는데, 이는 엄청난 양의
[02:51] 텍스트이며 여전히 상당히
[02:54] 정확합니다. 여기를 보시면
[02:55] 이것이 환각 비율입니다.
[02:57] 모르시는 분들을 위해 설명하자면,
[02:57] 환각은 AI 모델이
[03:00] 거짓 정보를 만들어낼 가능성을 의미하는데,
[03:02] Gemini의 최신 모델, 즉 Google의 최신
[03:04] 모델이 가장 낮은 환각
[03:06] 비율을 보여줍니다. 이러한 모델들은
[03:09] 2023년과 비교했을 때
[03:10] 매우 다릅니다. 제가 이 글을 작성했을 때
[03:12] RAG가 죽었다고 한 것은 전통적인
[03:15] 방식, 즉 하나의 문서를 가져와서
[03:18] 작은 청크로 나누는 것이
[03:20] 더 이상 필요하지 않다는 의미입니다. 코드를 보면
[03:22] 요즘은 약 20줄의 코드면 됩니다.
[03:25] ChatGPT를 사용해보셨거나
[03:28] Cursor나 Sonic과 같은 도구를 사용해보셨다면,
[03:30] 코딩이 가능하며, 정말 좋은 점은
[03:32] PDF 링크만 제공하면 된다는 것입니다.
[03:33] 임베딩 과정을 거치지 않아도 되므로
[03:36] 훨씬 더 쉬워졌습니다. 하지만
[03:38] 다루고 싶은 세부사항이 많이 있습니다.
[03:41] 이제 RAG에 대해 이해했으니
[03:43] 제가 왜 RAG가 '인용구로' 죽었다고 했는지
[03:45] 설명해드리겠습니다.
[03:48] 그리고 모델에 직접 컨텍스트를 제공해야 할 때와
[03:51] 그렇지 않을 때에 대한 명확한 사례를
[03:54] 몇 가지 알려드리겠습니다.
[03:56] 예를 들어, 음성 통화 기록의
[03:59] 시나리오를 살펴보겠습니다.
[04:01] 아주 긴 통화 기록이 있다고 가정해보죠.
[04:03] 매우 긴 기록인데,
[04:06] 예를 들어 실적 보고서라고 합시다.
[04:08] 실적 보고서에는
[04:11] 많은 내용이 담겨있죠.
[04:12] CEO가 말하는 내용들,
[04:14] 예를 들어 특정 재무상태나
[04:17] 회계연도의 실적, 사용한
[04:19] 기술 등 많은 내용을 다룹니다.
[04:22] 보통 한 시간 정도 길이이고,
[04:24] 간단히 말해서
[04:26] 약 5만 개의
[04:28] 토큰이라고 가정해보겠습니다.
[04:32] 즉, 5만 토큰의 실적 발표 통화 기록이 있는 거죠.
[04:37] 많은 사람들이 하는 방식은
[04:39] '와, 이걸
[04:41] 더 작은 조각으로 나누고 싶어'라고 생각하는 것입니다.
[04:42] 예를 들어
[04:45] 작은 조각들로 나누려고 할 때
[04:49] 한 조각당 512 토큰 정도로
[04:54] 나누는 거죠. 실제로 다양한
[04:58] 청킹 기술들이 있는데,
[04:59] 지금은 자세히 다루지 않겠습니다.
[05:02] 간단히 말해서
[05:03] 우리가 이 실적 발표를 가지고
[05:05] 이렇게 한다고 치면
[05:07] 우리는 이것을 가져와서
[05:08] 여러 개의 청크로 나눕니다.
[05:11] 약 100개 정도의
[05:13] 청크가 될 것입니다. 이런
[05:15] 시나리오에서 발생하는 문제,
[05:18] 단순한 청킹과 RAG에서
[05:21] 실제로 발생하는 문제는
[05:24] 내용을 추론할 수 없다는 것입니다. RAG에는
[05:27] 두 가지 주요 요소가 있는데, 사실과 정보를 찾을 수 있는가와
[05:30] 데이터를 추론할 수 있는가 입니다.
[05:31] 오늘날 RAG의 문제점은
[05:35] 청킹을 하고
[05:37] 임베딩을 할 때 정보를 추론할 수 없다는 것이며,
[05:41] 이 예시가 바로 그것을 보여줍니다.
[05:43] 이것이 완벽한 사용 사례인데, 예를 들어
[05:46] 내가 애널리스트이고 이 전사본을
[05:48] 분석하고 싶을 때, 만약 매우 구체적인
[05:51] 사실에 대해 질문한다면, 예를 들어
[05:53] 순수익이 얼마였는지 같은 질문은
[05:55] 찾기 쉬운 숫자죠. 사람이라면
[05:57] Ctrl+F로 검색해서
[05:59] revenue를 찾아보면 아마
[06:00] 빠르게 찾을 수 있을 겁니다. 이건 그다지
[06:02] 가치 있는 일이 아니죠. 2년 전에는
[06:05] 의미가 있었을지 모르지만 지금은 아닙니다.
[06:06] 대신 '그들의 실적 전망이 어떻게
[06:10] 다른 것과 비교되는지' 같은
[06:14] 질문을 할 수 있죠. 매우
[06:15] 복잡한 질문으로, 전사본 전체를 분석해야 하는
[06:18] 그런 질문을 할 수 있습니다.
[06:20] 예를 들어, 알고 싶은 게
[06:21] 전망이 어떤지, AI에게
[06:23] 물어보고 싶을 수 있죠. 이게 좋은
[06:24] 투자인지 나쁜 투자인지. 이제
[06:27] 이걸 어떻게 적절한 청크를 찾는 것으로 변환할까요?
[06:30] 청크 처리 과정에서 일반적으로
[06:33] 일어나는 일은, 사용자의 쿼리를 받아
[06:34] 기본적으로 가장 유사한
[06:36] 텍스트 청크를 찾으려고 시도하고
[06:39] 그것을 LLM에 전달하는 거죠. 전통적인 RAG는
[06:41] 작동하지 않습니다. 그렇게 할 수 없어요.
[06:44] 매우 복잡한 에이전트 기반 RAG가
[06:47] 필요하고, 할 수 있는 다양한 것들이
[06:49] 있지만 그건 완전히 다른 이야기죠.
[06:52] 하지만 그건 작동하지 않습니다. 이제
[06:53] 간단히 가정해봅시다. 이 전사본을
[06:56] 가져와서 단순히
[06:58] 이 코드 라인을 사용하고
[07:00] 이것을 Gemini에 전달한다고 해봅시다.
[07:02] Gemini는 추론 능력으로 전사본을 보고
[07:04] CEO가 특정한 것을 어떻게 말했는지
[07:06] 살펴볼 수 있고, 아마도 실적 보고서도
[07:09] 볼 수 있으며, 통화 시작 시
[07:11] 언급된 숫자들도 볼 수 있죠.
[07:14] 그들이 언급했을 수 있는
[07:15] 통화 시작 부분의 숫자들과
[07:16] 통화 끝부분을 볼 수 있고
[07:17] 중간에 답변한 질문들도
[07:19] 볼 수 있습니다. 통화 중간의 질문들도 볼 수 있죠.
[07:21] 50,000 토큰을 처리하며 추론할 수 있고
[07:26] 훨씬 더 나은, 더 정확한
[07:28] 답변을 당신의 질문에 제공할 수 있습니다.
[07:31] 이 개념이 바로 제가 RAG 킬러라고
[07:34] 말했을 때 의미한 것입니다.
[07:38] 많은 사람들이 RAG라고 생각하는 전통적인 방식은
[07:40] 하나의 문서, 하나의 PDF를 가지고
[07:43] PDF를 하나 또는 두 개 가지고 있고
[07:44] 그것에 대한 질문에 답하고 싶은 경우
[07:48] 그 방식은 이제 구식이 되었습니다.
[07:50] 더 이상 그렇게 할 필요가 없습니다.
[07:51] Gemini로 가서 구글의
[07:54] 모델을 사용할 수 있고
[07:56] AI 스튜디오로 가서 문서를
[07:58] 드래그 앤 드롭으로
[08:00] AI 스튜디오에
[08:02] 여기에서 원하는 모든 문서를
[08:05] 드래그해서 올리고
[08:07] 구글에 질문하면 됩니다. 저는 강력히 추천합니다.
[08:09] 여러분 모두가 이런 종류의
[08:12] 문서가 있다면 구글에 가서
[08:14] 업로드하세요. 더 나은 결과를
[08:16] 얻을 수 없을 테니까요. 하지만 RAG,
[08:19] 검색 증강 생성은 더 넓은 의미에서
[08:21] 죽지 않았습니다. 많은 정의가 있기 때문에
[08:23] 아주 좋은 예를 들어드리겠습니다.
[08:24] 때때로 사람들이 댓글에서
[08:27] 이렇게 말하곤 합니다. '만약 내가'
[08:29] 문서가 10만 개라면 어떻게 할까요?
[08:31] 2023년, 2024년, 2025년의 실적 발표가 있고,
[08:35] 그리고 어떤 이유에서인지
[08:37] AI에 업로드한 모든 파일 중에
[08:39] 엔비디아의 자료나,
[08:41] 애플에 대한 트랜스크립트,
[08:43] 엔비디아 자료도 있고,
[08:45] 관련 없는 문서들도 많이 있다면
[08:47] 이런 경우에는 RAG가 적용됩니다.
[08:51] 하지만 여기서 차이점은,
[08:53] 10만 개의 문서가 있을 때
[08:55] 여러분이 하고 싶은 것은
[08:57] 10만 개의 문서가 있다면
[08:59] 아마도 검색을 하실 거예요.
[09:00] 복잡하게 생각하지 말고
[09:02] 검색을 하고, 여러분은
[09:03] Ctrl+F가 아닌 다른 방식으로
[09:06] 이미 존재하는 많은 검색 시스템을
[09:08] 활용할 수 있습니다. 이제
[09:10] 애플의 실적 보고서를 모두 찾았다고
[09:13] 해봅시다. 좋습니다. 그러면 약
[09:16] 10개의 문서가 있을 텐데, 저는 여전히
[09:19] 이것들을 청킹하지 않을 것입니다. 왜냐하면
[09:21] 추론 능력을 잃게 되니까요.
[09:23] 대신에 제가 할 일은
[09:25] 10개의 문서를 Google Gemini에
[09:28] 각각 따로 보내는 겁니다. 자, 예를 들어보죠.
[09:30] 만약 제가
[09:31] 문서 1만 개가 있고 이것을 처리해야 한다면
[09:35] 3개로 필터링했다고 가정해보겠습니다.
[09:39] 최근에 제가 선호하는 방법은
[09:41] 비용이 조금 더 들더라도
[09:42] 병렬 처리를 하는 것입니다.
[09:44] 이것은
[09:45] 병렬화 기법인데
[09:47] 이 기술은 제가 트위터에서
[09:49] 발견했고, 많은 사람들이
[09:51] 최근에 이야기하고 있는 것으로
[09:52] Deep Seek 출시와 함께
[09:55] 기본적으로 하는 일은
[09:57] 3개나 5개 정도의
[10:00] 가장 관련성 높은 문서를 찾아서
[10:02] 512 토큰으로 청킹하는 대신
[10:04] AI 모델들이 요즘
[10:07] 매우 저렴해졌기 때문에 추천하는 방법은
[10:09] 이 문서들을 가져와서
[10:11] 세 개 모두를 병렬로
[10:13] Google Gemini에 보내는 것입니다. 제가
[10:17] 이걸 가져와서
[10:18] 찾는 대신에, 실제로
[10:20] 개별적으로 처리할 건데요,
[10:22] 같은 질문을 할 것이고
[10:24] 여러분이 보게 될 차이점은
[10:26] 직접 시도해보시면 알 수 있는데
[10:27] 질문에 대한 답변을 받을 때
[10:29] 엄청난 차이가 있습니다. 그래서 제가
[10:32] 이렇게 보고 말하죠.
[10:33] 사용자가 어떤 질문을 했다고 합시다.
[10:36] 사용자의 질문을 가져와서
[10:39] 동일한 질문을
[10:41] 세 개의 문서에 각각 따로 주고
[10:45] 이를 Gemini라고 부릅시다.
[10:48] Google 1,
[10:52] Google 2,
[10:55] Google 3이라고 하고
[10:58] 이것들을 가져와서 마지막으로
[11:01] 이 모든 것을 활용합니다. 모든 결과를
[11:04] 병합해서 최종적으로
[11:06] 사용자의 질문에 답하게 됩니다.
[11:08] 이것은 전혀 새로운 기술이 아닙니다.
[11:11] 일종의 맵리듀스와 같은 것으로
[11:13] 필터링하고
[11:16] 관련 없는 정보를 모두
[11:18] 제거하는 방식입니다. 다시 말하지만
[11:22] 제가 말씀드리고 싶은 것은
[11:24] 임베드 인 청크 방식은 더 이상 효과적이지 않습니다
[11:26] 이것이 바로 전통적인 RAG 시스템의 방식입니다
[11:27] 검색을 하면 세 개의 문서를 가져와서
[11:30] 이 문서들을 병렬로 처리하고
[11:33] 구글에게 각각을 따로 분석하게 하고
[11:34] 그 답변들을 취합한 다음
[11:36] 최종 답변을 다른 AI에게 전달하여
[11:38] 답을 얻습니다. 이것이 훨씬 더
[11:39] 견고한 시스템이며, 오늘날 모델들의
[11:42] 비용이 매우 저렴해졌기 때문에
[11:44] 특히 구글의 모델들은 비용이
[11:50] 매우 저렴하면서도 높은 품질의 답변을
[11:52] 제공하기 때문에 이것이 최선의 방법입니다
[11:55] 특히 환각 현상 발생률이 낮고
[11:56] 정보를 잘 찾아내는 능력이
[11:58] 뛰어나기 때문입니다. 이것으로
[11:59] 'RAG가 죽었다'는 포스트의 의미를
[12:01] 이해하실 수 있을 것 같습니다. RAG 킬러라고도 하죠
[12:07] 만약 여러분이 RAG를 구축하거나
[12:10] 관련 작업을 하신다면, 저는 단순하게
[12:12] 시작하시길 추천드립니다. 사람들은 보통
[12:14] 일을 복잡하게 만들기 좋아하는데, 개인 개발자라면
[12:16] 단순하게 유지하세요. 예를 들어
[12:20] 특정 시스템에 파일을 업로드하는 것처럼
[12:22] 간단하게 시작하고 복잡성이 필요할 때만
[12:24] 추가하세요. 많은 사람들이
[12:27] 불필요한 복잡성을 추가하길 좋아합니다
[12:29] 1년 후에는 상황이 달라질 수 있죠. 모델이 100배
[12:34] 더 저렴해지고 100배 더 효율적이 될 수도
[12:36] 있습니다. 어쩌면 이런 필터링 단계도
[12:38] 필요 없을 수 있죠. 하지만 결국
[12:40] 대부분의 사람들이 알고 있는 전통적인
[12:43] RAG 방식은, 특히 이 분야에
[12:45] 익숙하지 않은 분들이 보시기에
[12:47] 더 이상 존재할 이유가 없다고 봅니다
[12:50] 모든 데이터를 종합적으로 분석하여
[12:51] 충분한 답변을 제공할 수 없기 때문입니다
[12:53] 오늘 영상은 여기까지입니다
[12:55] 이를 통해 전통적인 RAG가 왜
[12:57] 작동하지 않는지, 그리고 왜 구글의
[12:59] Gemini 모델이 이런 종류의
[13:01] 사용 사례에서 특히 강력하고
[13:03] 유용한지 이해하셨길 바랍니다
[13:05] 제품을 개발하시든,
[13:07] 분석가로서 모든 문서를
[13:09] 읽어야 하는 사람이든
[13:10] 구글의 새로운 모델은 매우 유용합니다
[13:12] 그리고 한 가지 더 추가하자면
[13:13] 이 과정에서 AI 모델을
[13:16] 혼합해서 사용할 수 있습니다
[13:18] 매우 저렴한 모델을 사용해서
[13:20] 모든 문서를 분석하게 하고
[13:22] 그 답변들을 가져와서
[13:24] 정말 원한다면
[13:26] Pro-01이나 03 같은
[13:27] 더 똑똑한 모델에게 전달할 수 있습니다
[13:30] AI 모델이 알맞은 청크를
[13:32] 선택하게 하는 것보다 훨씬 효과적이죠
[13:34] 더 똑똑한 모델에게 전달할 수 있습니다
[13:36] AI 모델이 올바른 청크를
[13:39] 선택하게 하는 것은 효과가 없습니다
[13:41] 이상입니다. 영상 시청해 주셔서 감사합니다
[13:43] 안녕히 계세요