소개

Google은 Gemini File Search를 발표했으며 전문가들은 이것이 자체 제작 RAG(Retrieval Augmented Generation)의 사망자 수라고 주장합니다. 그 이유는 이제 앱 개발자가 더 이상 청킹, 임베딩, 파일 저장, 벡터 데이터베이스, 메타데이터, 검색 최적화, 컨텍스트 관리 등에 대해 걱정할 필요가 없기 때문입니다. 그리고 전체 문서 Q&A 스택(미들웨어와 애플리케이션 레이어 로직으로 사용됨)은 이제 Gemini 모델과 주변 클라우드 제품에 흡수됩니다.

\ 이 기사에서는 Gemini 파일 검색을 시험해 보고 기능, 성능, 비용, 유연성 및 투명성 측면에서 자체 RAG 시스템과 비교할 것입니다. 귀하의 사용 사례에 대해 현명한 결정을 내릴 수 있습니다. 그리고 귀하의 개발 속도를 높이기 위해 다음을 포함시켰습니다. GitHub의 예시 앱.

\ 원본은 여기 구글 발표:

나만의 에이전트 RAG 구축

Traditional RAG – 재교육

전통적인 RAG의 아키텍처는 다음과 같으며 몇 가지 순차적 단계로 구성됩니다.

문서는 먼저 청크로 분할되어 포함되어 벡터 데이터베이스에 삽입됩니다. 종종 관련 메타데이터가 데이터베이스 항목에 포함됩니다.
사용자 쿼리를 삽입하여 벡터 DB 검색으로 변환하여 해당 청크를 검색했습니다.
마지막으로 원래 사용자 쿼리와 검색된 청크(컨텍스트)가 AI 모델에 입력되어 사용자를 위한 답변을 생성합니다.

에이전트릭 RAG

Agentic RAG 시스템의 아키텍처에는 에이전트가 결과가 관련성이 있고 완전한지 확인한 다음 검색 품질을 만족시키기 위해 쿼리를 다시 작성하는 반사 및 반응 루프가 추가되었습니다. 따라서 AI 모델은 사용자 쿼리를 벡터 DB 쿼리로 다시 작성하고, 검색이 만족스러운지 평가하고, 최종적으로 사용자를 위한 답변을 생성하는 등 여러 곳에 사용됩니다.

사용 사례 예시 – 카메라 매뉴얼 Q&A

오래된 필름 카메라를 사용하는 데 관심이 있는 새로운 사진가들이 많이 있습니다. 이들의 주요 과제 중 하나는 많은 오래된 카메라가 필름 로드 및 필름 프레임 카운터 재설정과 같은 기본적인 작업까지 독특하고 때로는 기발한 작동 방식을 가지고 있다는 것입니다. 더 나쁜 것은 특정 작업을 “잘못된 순서”로 수행하면 카메라가 손상될 수도 있다는 것입니다. 따라서 카메라 매뉴얼의 정확하고 정확한 지침이 필수적입니다.

\ 카메라 매뉴얼 아카이브에는 9,000개의 오래된 카메라 매뉴얼이 있으며 대부분 스캔된 PDF입니다. 이상적인 세상에서는 카메라용으로 몇 가지를 다운로드하고 연구하고 익숙해지면 작업이 완료됩니다. 그러나 우리는 모두 인내심도 없고 계획도 없는 현대인이다. 따라서 이동 중에(예: 전화 앱에서) 카메라 설명서 PDF에 대한 Q&A가 필요합니다.

\ 이것은 에이전트 RAG 범위에 매우 잘 맞습니다. 그리고 나는 이것이 오래된 사용자 매뉴얼에서 정보를 찾아야 하는 많은 취미(음악 악기, Hi-Fi 장비, 빈티지 자동차)에 보편적으로 적용될 것이라고 가정합니다.

PDF Q&A용 Homebrew RAG

우리의 RAG 시스템은 올해 초에 구현되었습니다. LLaMAIndex RAG 워크플로 상당한 사용자 정의:

Qrrant 벡터 데이터베이스 사용: 가격 대비 성능이 좋고 메타데이터를 지원합니다.
Mistral OCR API를 사용하여 PDF를 수집합니다. 그림과 표가 포함된 복잡한 PDF 파일을 이해하는 데 좋은 성능을 발휘합니다.
사용자가 텍스트 지침 외에도 복잡한 카메라 작동에 대한 그래픽 일러스트레이션에 직접 액세스할 수 있도록 각 PDF 페이지의 이미지를 보관하세요.
반영의 에이전트 루프를 추가하고 다음을 기반으로 반응합니다. 에이전트 검색을 위한 Google/Langchain 예시.

다중 모드 LLM은 어떻습니까?

2024년부터 다중 모드 LLM은 이미 정말 좋아지고 있습니다. 확실한 대안 접근 방식은 사용자 쿼리와 전체 PDF를 LLM에 제공하고 답변을 얻는 것이었습니다. 이는 벡터 DB나 미들웨어를 유지할 필요가 없는 훨씬 간단한 솔루션입니다.

\ 우리의 주요 관심사는 비용이므로 비용 계산 및 비교를 수행했습니다. 짧은 대답은 하루에 사용자 쿼리 수가 10보다 크면 RAG가 더 빠르고 효율적이며 비용이 훨씬 저렴하다는 것입니다. 따라서 “사용자 쿼리 및 전체 일치 PDF를 다중 모달 LLM에 직접 공급”하는 것은 실제로 프로토타입 제작 또는 매우 적은 양의 사용(하루 몇 개의 쿼리)에만 효과적입니다.

\ 당시에는 Google이 Gemini 파일 검색을 중단할 때까지 홈브류 RAG가 여전히 매우 중요하다는 우리의 믿음이 확인되었습니다. 더 이상 결정이 그렇게 간단하지 않다고 생각합니다.

Gemini 파일 검색 – 예

Google AI Studio 예제를 기반으로 카메라 수동 Q&A 사용 사례에 대한 예제 앱을 구축했습니다. 그것은 GitHub의 오픈 소스, 매우 빠르게 시도해 볼 수 있습니다. 다음은 사용자 인터페이스와 채팅 스레드의 스크린샷입니다.

Gemini 파일 검색을 사용한 PDF Q&A 예시:

\ 소스 코드와 관련된 주요 단계:

파일 검색 저장소를 생성하고 여러 세션에서 유지합니다.
여러 파일을 동시에 업로드하면 Google 백엔드가 모든 청크 및 삽입을 처리합니다. 사용자를 위한 샘플 질문도 생성됩니다. 또한 청크 전략을 수정하고 사용자 정의 메타데이터를 업로드할 수 있습니다.
RAG(표준 생성 쿼리) 실행: 내부적으로는 에이전트이며 최종 답변을 생성하기 전에 결과의 품질을 실제로 평가할 수 있습니다.

추가 개발자 정보

Gemini 파일 검색 API 문서

\ Phil Schmidt의 튜토리얼

Gemini 파일 검색 가격

개발자에게는 기존 기반을 기반으로 색인 생성 시 임베딩에 대한 비용이 청구됩니다. 임베딩 가격 (100만 토큰당 $0.15).
보관은 무료입니다.
쿼리 시간 임베딩은 무료입니다.
검색된 문서 토큰은 일반 토큰으로 청구됩니다. 컨텍스트 토큰.

그렇다면 어느 것이 더 낫습니까?

Gemini 파일 검색은 아직 상당히 새롭기 때문에 내 평가는 순전히 약 일주일 동안의 초기 테스트를 기반으로 합니다.

역량 비교

Gemini 파일 검색에는 홈브루 RAG 시스템의 모든 기본 기능이 있습니다.

청킹(크기 및 겹침 구성 가능)
임베딩
맞춤형 메타데이터 입력을 지원하는 벡터 DB
검색
생성적 출력

\ 그리고 내부에 포함된 고급 기능:

검색 품질을 평가하는 에이전트 기능

\ 문제를 해결해야 한다면 현재 이미지 출력이 누락되었습니다. 지금까지 Google 파일 검색의 출력은 텍스트로만 제한되어 있었지만 맞춤 제작된 RAG는 스캔한 PDF에서 이미지를 반환할 수 있습니다. 앞으로는 Gemini File Search가 다중 모드 출력을 제공하는 것이 그리 어렵지 않을 것이라고 생각합니다.

성능 비교

정확도: 동등 검색이나 생성 품질에는 실질적인 개선이 없습니다.

속도 : 대부분 동등합니다. Gemini 파일 검색은 벡터 DB와 LLM이 모두 Google Cloud 인프라 내부에 ‘위치’되어 있으므로 약간 더 빠를 수 있습니다.

비용 비교

마지막으로 Gemini File Search는 비용이 많이 드는 완전 호스팅 시스템입니다. 더 적은 홈브류 시스템보다

\ 문서 임베딩은 한 번만 실행되었으며 비용은 백만 토큰당 0.15달러입니다. 이는 모든 RAG 시스템에 공통적으로 적용되는 고정 비용이며, 문서 Q&A 애플리케이션의 수명 동안 상환될 수 있습니다. 제가 카메라 매뉴얼을 사용하는 경우 이 고정 비용은 전체 비용에서 아주 작은 부분입니다.

\ Gemini 파일 검색은 “무료” 파일 저장소와 데이터베이스를 제공하므로 이는 홈브루 RAG 시스템에 비해 절약됩니다.

\ 입력 토큰(질문과 컨텍스트로서의 벡터 검색 결과) 및 출력 토큰의 양이 Gemini 파일 검색과 홈브루 시스템 간에 비슷하기 때문에 추론 비용은 거의 동일합니다.

튜닝 및 디버깅을 위한 유연성 및 투명성

당연히 Gemini 파일 검색은 내장 및 추론을 위해 Gemini AI 모델과 결합합니다. 본질적으로 유연성과 선택권을 희생하면서 편리함을 얻고 있습니다.

\ RAG 시스템을 미세 조정하는 측면에서 Gemini 파일 검색은 일정 수준의 사용자 정의를 제공합니다. 예를 들어, 업로드 중에 ChunkingConfig를 정의하여 maxTokensPerChunk 및 maxOverlapTokens와 같은 매개변수를 지정하고 customMetadata를 문서에 키-값 쌍을 첨부하도록 정의할 수 있습니다.

\ 그러나 디버깅 및 성능 튜닝을 위한 Gemini 파일 검색 시스템의 내부 추적은 불가능해 보입니다. 그래서 블랙박스처럼 활용하고 있는 것입니다.

결론

Google의 Gemini 파일 검색은 매우 매력적인 가격으로 대부분의 애플리케이션과 대부분의 사람들에게 충분합니다. 사용하기 매우 쉽고 운영 오버헤드가 최소화됩니다. 빠른 프로토타이핑 및 모형 제작에 적합할 뿐만 아니라 수천 명의 사용자가 있는 프로덕션 시스템에도 충분합니다.

\ 그러나 홈브류 RAG 시스템을 고려할 수 있는 몇 가지 시나리오는 다음과 같습니다. \n

귀하는 귀하의 독점 문서를 호스팅하는 데 Google을 신뢰하지 않습니다.
원본 문서의 이미지를 사용자에게 반환해야 합니다.
임베딩 및 추론에 사용할 LLM, 청크 수행 방법, RAG의 에이전트 흐름 제어 방법, 잠재적인 검색 품질 문제 디버깅 방법 측면에서 완전한 유연성과 투명성이 필요합니다.

\ 따라서 Gemini 파일 검색을 시도해 보고 스스로 결정하십시오. 다음 중 하나를 사용할 수 있습니다. 구글 AI 스튜디오 놀이터로 사용하거나 GitHub의 예제 코드. 귀하의 사용 사례에 대한 결과에 대해 아래에 의견을 남겨주십시오.

출처 참조