소개 Google은 Gemini File Search를 발표했으며 전문가들은 homebrew RAG (Retrieval Augmented Generation)의 사망자라고 주장합니다.이 이유는 이제 애플리케이션 개발자가 더 이상 chunking, embedding, 파일 저장, 벡터 데이터베이스, 메타데이터, 검색 최적화, 컨텍스트 관리 등을 걱정할 필요가 없다는 것입니다. 이 기사에서는 Gemini 파일 검색을 시도하고 기능, 성능, 비용, 유연성 및 투명성 측면에서 homebrew RAG 시스템과 비교할 것입니다.You will be able to make an educated decision for your use case. . GitHub에 있는 My Example App GitHub에 있는 My Example App 이곳은 원본 : Google 발표 Google 발표 당신의 자신의 에이전트 RAG를 구축 전통적인 RAG - A Refresher 전통적인 RAG의 아키텍처는 몇 가지 연속 단계로 구성된 다음과 같습니다. 문서는 먼저 분쇄, 삽입 및 벡터 데이터베이스에 삽입됩니다.Often, related metadata are included in the database entries. 사용자 쿼리는 삽입되어 벡터 DB 검색으로 변환하여 관련 조각을 검색했습니다. 그리고 마지막으로, 원본 사용자 쿼리와 검색된 조각(인 컨텍스트)은 AI 모델에 공급되어 사용자를 위한 답을 생성합니다. 에이전트 RAG Agentic RAG 시스템의 아키텍처는 반사 및 반응 루프를 추가하여 에이전트가 결과가 관련적이고 완전한지 확인한 다음 검색 품질을 충족시키기 위해 쿼리를 다시 작성합니다.So, the AI model is used in several places: to rewrite the user query into a vector DB query, to assess whether the retrieval is satisfactory, and finally to generate the answer for the user. 카메라 매뉴얼 Q&A 오래된 필름 카메라를 사용하는 데 관심이있는 많은 새로운 사진 작가가 있습니다. 그들에게 가장 큰 도전 중 하나는 많은 오래된 카메라가 영화를 로딩하고 필름 프레임 카운터를 재설정하는 것과 같은 기본적인 것들조차도 작동하는 독특하고 때로는 이상한 방법을 가지고 있다는 것입니다. 더 나쁜 것은 "잘못된 순서로"일 경우 카메라를 손상시킬 수 있습니다. 카메라 매뉴얼 아카이브는 9,000 개의 오래된 카메라 매뉴얼, 대부분 스캔 된 PDF를 호스팅합니다. 이상적인 세계에서는 카메라를 위해 몇 개를 다운로드하고, 그들을 공부하고, 익숙해지고, 그것에 익숙해 질 수 있습니다. 그러나 우리는 모두 인내심이나 사전 계획이없는 현대 인간입니다. 그리고 나는 그것이 고대 사용자 매뉴얼에서 정보를 찾을 필요가있는 많은 취미 (음악 기계, Hi-Fi 장비, 빈티지 자동차)에 보편적으로 적용 될 것이라고 가정합니다. Homebrew RAG for PDF Q&A 우리의 RAG 시스템은 올해 초에 구현되었으며, 상당한 customization : LLaMAIndex RAG 워크플로우 LLaMAIndex RAG 워크플로우 Qrrant 벡터 데이터베이스 사용: 좋은 가격과 성능 비율, 지원 메타데이터. Mistral OCR API를 사용하여 PDF를 흡수하십시오 : 그림과 테이블을 포함한 복잡한 PDF 파일을 이해하는 데 좋은 성능. 각 PDF 페이지의 이미지를 보관하여 사용자가 텍스트 지침 외에도 복잡한 카메라 작업의 그래픽 이미지를 직접 액세스할 수 있습니다. 에이전트 검색을위한 Google/Langchain 예를 기반으로 반사 및 반응의 에이전트 루프를 추가합니다. Google/Langchain 예제 에이전트 검색 Multi-Modal LLM은 어떻게 하나요? 2024 년부터 멀티 모탈 LLM은 이미 정말로 잘되고 있습니다. 명백한 대안 접근 방식은 사용자 쿼리와 전체 PDF를 LLM에 전달하고 답변을 얻는 것이 었습니다. 이것은 벡터 DB 또는 중간 소프트웨어를 유지할 필요가없는 훨씬 더 간단한 솔루션입니다. 우리의 주된 우려는 비용이었다, 그래서 우리는 비용 계산과 비교를했다.그리고 짧은 대답은 RAG가 하루에 사용자 쿼리 수가 10보다 많을 때 더 빠르고, 더 효율적이며, 훨씬 저렴한 비용을 지불한다는 것입니다. 그 당시, 그것은 Google이 Gemini 파일 검색을 떨어 뜨릴 때까지 homebrew RAG가 여전히 중요하다는 우리의 믿음을 확인했다. 쌍둥이 파일 검색 - 예제 Google AI Studio 예를 바탕으로 카메라 매뉴얼 Q&A 사용 케이스에 대한 예제 앱을 구축했습니다. 그래서 당신은 매우 빨리 그것을 시도할 수 있습니다.여기에 사용자 인터페이스와 채팅 스레드의 스크린샷이 있습니다. , GitHub에서 오픈소스 GitHub에서 오픈소스 Gemini File Search를 사용하여 PDF와의 Q&A 예제: https://github.com/zbruceli/pdf_qa https://github.com/zbruceli/pdf_qa 원본 코드에 관련된 주요 단계 : The main steps involved in the source code: 파일 검색 스토어를 만들고 다른 세션을 통해 그것을 지속하십시오. 여러 파일을 동시에 업로드하고 Google 백엔드는 모든 크링 및 삽입을 처리합니다. 사용자를 위해 샘플 질문을 만들기도합니다.또한 크링 전략을 수정하고 사용자 지정 메타데이터를 업로드할 수 있습니다. Standard Generation Query (RAG)를 실행하십시오 : 장면 뒤에, 그것은 에이전틱하고 실제로 최종 답변을 생성하기 전에 결과의 품질을 평가할 수 있습니다. 더 많은 개발자 정보 Gemini File Search API 문서 https://ai.google.dev/gemini-api/docs/file-search https://ai.google.dev/gemini-api/docs/file-search 튜토리얼 Phil Schmidt https://www.philschmid.de/gemini-file-search-javascript https://www.philschmid.de/gemini-file-search-javascript Gemini File Search에 대한 정보 개발자는 기존의 삽입 가격 ($0.15 / 1M 토큰)에 따라 인덱싱 시간에 삽입에 대해 청구됩니다. 저장비는 무료입니다. Query Time Embeddings는 무료입니다. 복구된 문서 토큰은 정규 컨텍스트 토큰으로 청구됩니다. 삽입 가격 토큰 컨텍스트 그렇다면 어느 것이 더 낫습니까? Gemini 파일 검색은 여전히 상당히 새롭기 때문에, 내 평가는 약 일주일간의 초기 테스트를 기반으로합니다. 능력 비교 Gemini 파일 검색은 homebrew RAG 시스템의 모든 기본 기능을 가지고 있습니다. Chunking (Size 및 Overlap를 구성할 수 있음) 삽입 사용자 지정 메타데이터 입력을 지원하는 Vector DB 리트리얼 Generative 출력 그리고 모드 아래의 더 진보 된 기능 : 복구 품질을 평가할 수 있는 에이전트 능력 지금까지 Google 파일 검색의 출력은 텍스트만으로 제한되며, 사용자 지정된 RAG는 스캔 된 PDF에서 이미지를 반환 할 수 있습니다. 성능 비교 정밀성: 수신 또는 생성 품질에 대한 실질적인 개선은 없습니다. Gemini File Search는 벡터 DB와 LLM이 모두 Google Cloud 인프라 내부에 "앉아" 있기 때문에 약간 빠를 수 있습니다. 비용 비교 마지막으로, Gemini File Search는 비용이 들 수 있는 완전히 호스팅된 시스템입니다. Homebrew 시스템을 사용하는 것보다 less 문서의 삽입은 한 번만 실행되었으며 백만 토큰당 $0.15의 비용입니다.이것은 모든 RAG 시스템에 공통적인 고정 비용이며 문서 Q&A 응용 프로그램의 수명 내내에 보상 될 수 있습니다. Gemini File Search는 "무료"파일 스토리지 및 데이터베이스를 제공하기 때문에, 이것은 homebrew RAG 시스템에 대한 절약입니다. 입력 토큰 (문제 플러스 벡터 검색 결과를 컨텍스트로)과 출력 토큰의 양은 Gemini File Search와 homebrew 시스템 사이에 비교할 수 있기 때문에 추론 비용은 거의 동일합니다. 조정 및 디버깅을 위한 유연성 및 투명성 당연히 Gemini File Search는 삽입 및 추론을위한 Gemini AI 모델과 당신을 결혼시킵니다. RAG 시스템을 정렬하는 측면에서 Gemini File Search는 특정 수준의 사용자 정의를 제공합니다. 예를 들어, 업로드 중 chunkingConfig를 정의하여 maxTokensPerChunk 및 maxOverlapTokens와 같은 매개 변수를 지정할 수 있으며, 문서에 키 값 쌍을 첨부할 수 있는 customMetadata를 지정할 수 있습니다. 그러나 디버깅 및 성능 조정을 위해 Gemini File Search 시스템의 내부 흔적을 갖는 것은 불가능한 것 같습니다. 결론 구글의 쌍둥이 파일 검색은 대부분의 응용 프로그램과 대부분의 사람들에게 매우 매력적인 가격으로 충분히 좋습니다. 그것은 매우 사용하기 쉽고 최소한의 운영 능력이 있습니다. 그것은 빠른 프로토 타입 및 패키지 제작뿐만 아니라 수천 명의 사용자가있는 생산 시스템에도 충분히 좋습니다. 그러나 Homebrew RAG 시스템을 여전히 고려할 수있는 몇 가지 시나리오가 있습니다. 귀하의 소유 문서를 호스팅하는 Google을 신뢰하지 않습니다. 원본 문서에서 이미지를 사용자에게 반환해야합니다. 당신은 LLM이 삽입 및 추론을 위해 사용하는 것과 관련하여 완전한 유연성과 투명성을 원하며, chunking을 수행하는 방법, RAG의 에이전트 흐름을 제어하는 방법, 잠재적 인 검색 품질 문제를 해결하는 방법을 원합니다. 그래서, Gemini 파일 검색을 시도하고 스스로 결정할 수 있습니다. 놀이장으로, 또는 당신은 사용할 수 있습니다 당신의 사용 사례에 대한 당신의 발견에 대해 아래에 코멘트하십시오. Google AI 스튜디오 GitHub에서 내 코드 예제 Google AI 스튜디오 GitHub에서 내 코드 예제
