Поисковый гигант наносит очередной удар по традиционной обработке RAG.
Делиться
Большие языковые модели (LLM), такие как Gemini, произвели революцию в разработке программного обеспечения. Их способность понимать, генерировать и рассуждать о тексте поразительна. Однако у них есть фундаментальное ограничение: они знают только то, чему их учили. Им неизвестна внутренняя документация вашей компании, конкретная кодовая база вашего проекта или последняя опубликованная вчера исследовательская работа.
Для создания интеллектуальных и практических приложений нам необходимо преодолеть этот разрыв и обосновать обширные возможности модели в области рассуждений на основе ваших собственных, конфиденциальных данных. Это область применения метода расширенной генерации (RAG). Этот мощный метод извлекает релевантную информацию, как правило, из внешней базы знаний. Затем он предоставляет её в качестве контекста для получения более точных, адекватных и проверяемых ответов на вопросы.
Несмотря на высокую эффективность, создание надежного трубопровода RAG с нуля представляет собой сложную инженерную задачу. Это включает в себя сложную последовательность этапов:
- Приём и разбиение данных на фрагменты. Анализ различных форматов файлов (PDF, DOCX и т. д.) и их разумное разделение на более мелкие, семантически значимые фрагменты.
- Генерация вложений. Использование модели вложения для преобразования текстовых фрагментов в числовые векторные представления.
- Хранилище векторных данных. Настройка, управление и масштабирование выделенной базы данных векторных данных для хранения векторных изображений для эффективного поиска.
- Логика поиска. Реализация системы, которая принимает запрос пользователя, встраивает его и выполняет поиск по сходству в базе данных векторов для нахождения наиболее релевантных фрагментов.
- Внедрение контекста. Динамическая вставка полученных фрагментов в запрос для LLM таким образом, чтобы он мог эффективно использовать эту информацию. Каждый из этих шагов требует тщательного продумывания, управления инфраструктурой и постоянного обслуживания.
Каждый из этих шагов требует тщательного рассмотрения, управления инфраструктурой и постоянного обслуживания.
Недавно, продолжая попытки положить конец традиционному RAG в его нынешнем виде, Google выкупила ещё один новый продукт, ориентированный на эту область. Новый инструмент поиска файлов от Google полностью избавляет от необходимости разбивать документы на фрагменты, встраивать их и векторизовать перед выполнением семантического поиска.
Что такое инструмент поиска файлов Google?
По своей сути, инструмент поиска файлов представляет собой мощный уровень абстракции для всего конвейера RAG. Он обрабатывает весь жизненный цикл ваших данных, от получения до извлечения, предоставляя простой, но эффективный способ использовать ответы Gemini в ваших документах.
Давайте разберем его основные компоненты и проблемы, которые они решают.
1) Простой, интегрированный интерфейс разработчика
Поиск файлов — это не отдельный API или сложный внешний сервис, требующий настройки. Он реализован как инструмент непосредственно в существующем Gemini. API . Эта бесшовная интеграция позволяет вам добавлять мощные возможности RAG в ваше приложение всего несколькими строками кода. Инструмент автоматически…
- Надежно хранит загруженные вами документы.
- Применяет сложные стратегии для разбиения документов на связные части подходящего размера для достижения наилучших результатов поиска.
- Обрабатывает ваши файлы, генерирует вложения с использованием современных моделей Google и индексирует их для быстрого поиска.
- Выполняет поиск и внедряет соответствующий контекст в подсказку, отправленную в Gemini.
2) Мощный векторный поиск в его основе
Поисковый механизм основан на модели gemini-embedding-001 , разработанной для высокопроизводительного семантического поиска. В отличие от традиционного поиска по ключевым словам, который находит только точные совпадения, векторный поиск учитывает смысл и контекст запроса. Это позволяет ему находить релевантную информацию в ваших документах, даже если запрос пользователя содержит совершенно другую формулировку.
3) Встроенные ссылки для проверяемости
Доверие и прозрачность критически важны для корпоративных приложений искусственного интеллекта. Инструмент поиска файлов автоматически включает базовые метаданные в ответ модели. Эти метаданные содержат ссылки, точно указывающие, какие части исходных документов были использованы для получения ответа.
Это важная функция, которая позволяет вам:
- Проверка точности. Легко проверяйте источники модели, чтобы убедиться в правильности её ответа.
- Повышайте доверие пользователей. Покажите пользователям, откуда поступает информация, тем самым повышая их доверие к системе.
- Обеспечивает более глубокое изучение. Предоставляет ссылки на исходные документы, позволяя пользователям более подробно изучать интересующие их темы.
4. Поддержка широкого спектра форматов.
База знаний редко состоит из простых текстовых файлов. Инструмент поиска файлов поддерживает широкий спектр стандартных форматов файлов, включая PDF, DOCX, TXT, JSON, а также различные форматы файлов языков программирования и приложений. Эта гибкость позволяет создать комплексную базу знаний из существующих документов без необходимости выполнять сложную предварительную обработку или преобразование данных.
5. Доступность
Google сделал использование своего инструмента поиска файлов невероятно экономичным. Хранение и встраивание запросов бесплатны. Вы платите только за встраивание исходного содержимого документа, стоимость которого может составлять всего 0,15 доллара США за 1 миллион токенов (например, на основе модели встраивания gemini-embedding-001).
Использование поиска файлов
Теперь, когда мы лучше понимаем, что такое инструмент поиска файлов, пора посмотреть, как его можно использовать в наших рабочих процессах. Для этого я покажу вам пример кода на Python, который покажет, как вызывать и использовать поиск файлов.
Однако перед этим лучше всего настроить отдельную среду разработки, чтобы изолировать наши различные проекты друг от друга.
Я буду использовать UV-инструмент для этого и запущу свой код в Jupyter Notebook под управлением WSL2 Ubuntu для Windows. Вы также можете использовать любой удобный вам менеджер пакетов.
$ cd projects $ uv init gfs $ cd gfs $ uv venv $ source gfs/bin/activate (gfs) $ uv pip install google-genai jupyter
Вам также понадобится ключ API Gemini, который можно получить на домашней странице Google AI Studio по ссылке ниже.
Студия искусственного интеллекта Google
После входа в систему найдите ссылку «Получить ключ API» в левом нижнем углу экрана.
Пример кода — простой поиск в PDF-документе
Для тестирования я скачал руководство пользователя для мобильного телефона Samsung S25 с их сайта на свой локальный компьютер. Оно объёмом более 180 страниц. Вы можете получить его по этой ссылке.
Запустите Jupyter Notebook и введите следующий код в ячейку.
import time from google import genai from google.genai import types client = genai.Client(api_key='YOUR_API_KEY') store = client.file_search_stores.create() upload_op = client.file_search_stores.upload_to_file_search_store( file_search_store_name=store.name, file='SM-S93X_UG_EU_15_Eng_Rev.2.0_250514.pdf' ) while not upload_op.done: time.sleep(5) upload_op = client.operations.get(upload_op) # Используйте хранилище поиска файлов как инструмент в вашем вызове генерации response = client.models.generate_content( model='gemini-2.5-flash', content='К каким моделям телефонов относится этот документ …', config=types.GenerateContentConfig( tools=[types.Tool( file_search=types.FileSearch( file_search_store_names=[store.name] ) )] ) ) print(response.text)
После импорта необходимых библиотек мы создаём «хранилище поиска файлов» — контейнер для данных и индексов загруженных файлов. Затем мы загружаем в хранилище наш входной файл и дожидаемся завершения загрузки.
Затем мы вызываем функцию generate_content , которая ответит на вопрос, который мы задали нашей выбранной модели (в нашем примере Gemini 2.5 flash) о нашем входном файле, прежде чем распечатать ответ модели.
Вот ответ, который я получил при запуске приведенного выше кода.
Этот документ относится к следующим моделям телефонов: SM-S931B, SM-S931B/DS, SM-S936B, SM-S936B/DS, SM-S937B, SM-S937B/DS, SM-S938B и SM-S938B/DS. Также в нём упоминаются Galaxy S25 Ultra, Galaxy S25 Edge, Galaxy S25+ и Galaxy S25.
Мы можем проверить точность этой информации, изучив первую страницу PDF-файла, где представлен список соответствующих моделей.
Давайте копнём немного глубже и найдём более каверзный вопрос. Допустим, вы хотите узнать, как автоматически выключать экран, когда он не используется. На странице 156 PDF-файла написано следующее:
Вы можете настроить автоматическое отключение экрана, когда он не используется. Откройте «Настройки», выберите «Дисплей» → «Время ожидания экрана» и выберите время, по истечении которого устройство должно выключить экран.
Может ли инструмент поиска файлов определить это?
… … … # Используйте хранилище поиска файлов как инструмент при генерации вызова response = client.models.generate_content( model='gemini-2.5-flash', content='Как настроить автоматическое отключение экрана при неиспользовании', config=types.GenerateContentConfig( tools=[types.Tool( file_search=types.FileSearch( file_search_store_names=[store.name] ) )] ) ) print(response.text)
И каков ответ?
Чтобы настроить автоматическое отключение экрана устройства при бездействии, можно настроить параметр «Время ожидания экрана». Этот параметр определяет время, по истечении которого устройство выключает подсветку дисплея. На устройствах Samsung (как указано в прилагаемом руководстве пользователя) этот параметр обычно находится в разделе «Настройки» → «Дисплей» → «Время ожидания экрана». Там можно выбрать желаемый период времени, по истечении которого экран отключается.
Имейте в виду, что File Search также может использовать внутреннюю базу знаний своей модели при ответе на вопросы, без необходимости обращаться к хранилищу документов, чтобы найти ответ.
Работа с несколькими входными файлами
Если ваш корпус документов состоит из нескольких файлов, их легко объединить с помощью простого цикла for, но следует учитывать некоторые ограничения поиска файлов. Согласно документации Google, эти ограничения таковы:
API поиска файлов имеет следующие ограничения для обеспечения стабильности работы сервиса:
Максимальный размер файла/ограничение на один документ: 100 МБ
Общий размер хранилищ поиска файлов проекта (в зависимости от уровня пользователя):
Бесплатно: 1 ГБ
Уровень 1: 10 ГБ
Уровень 2: 100 ГБ
Уровень 3: 1 ТБ
Управление фрагментацией
При добавлении файла в хранилище поиска файлов система автоматически разбивает его на более мелкие фрагменты, встраивает и индексирует содержимое, а затем загружает его. Если вы хотите более точно настроить сегментацию, используйте параметр chunking_config , чтобы установить ограничения на размер фрагмента и указать, сколько токенов должно перекрываться между фрагментами. Вот фрагмент кода, демонстрирующий, как это сделать.
… … операция = клиент.файловые_хранилища_поиска.загрузка_в_файловое_хранилище(имя_файлового_хранилища_поиска=имя_файлового_хранилища_поиска, файл='SM-S93X_UG_EU_15_Eng_Rev.2.0_250514.pdf' конфигурация={ 'конфигурация_разбиения': { 'конфигурация_белого_пространства': { 'макс._токенов_на_блок': 200, 'макс._токенов_перекрытия': 20 } } } ) … …
Чем File Search отличается от других инструментов Google, связанных с RAG, таких как Context Grounding и LangExtract?
Недавно я написал статьи о двух похожих продуктах Google в этой области: Context Grounding и LangExtract. На первый взгляд, они делают схожие вещи. И это действительно так — до определённого момента.
Главное отличие заключается в том, что File Search — это полноценный продукт RAG, поскольку он сохраняет вложения ваших документов постоянно, в отличие от двух других инструментов. Это означает, что после того, как ваши вложения попали в хранилище File Search, они остаются там навсегда или до тех пор, пока вы их не удалите. Вам не придётся заново загружать файлы каждый раз, когда вы хотите ответить на вопрос по ним.
Ниже приведена удобная таблица различий для справки.
+———————+—————————————+——————————————————-+——————————————————-+ | Функция | Поиск файлов Google | Google Context Grounding | LangExtract | +—-+——————————————————-+——————————————————-+——————————————————-+ | Основная цель | Отвечать на вопросы и генерировать | Связывает ответы модели с проверенными | Извлекать определенные структурированные данные | | | контентом из частных документов. | источников для повышения точности и | (например, JSON) из неструктурированного текста. | | | | уменьшить галлюцинации. | | +———————+—————————————+——————————————————-+——————————————————-+ | Ввод | Пользовательский запрос и загруженные файлы | Пользовательский запрос и настроенные данные | Неструктурированный текст плюс схема или | | | источник (например, поиск Google, URL). | подсказка, описывающая, что извлекать. | +———————+—————————————+——————————————————-+——————————————————-+ | Вывод | Разговорный ответ, основанный на | Ответ на естественном языке, проверенный фактами | Сопоставление структурированных данных (например, JSON) | | | предоставленных файлов с цитатами. | со ссылками или отсылками. | информации в исходный текст. | +———————+—————————————+——————————————————-+——————————————————-+ | Базовый процесс | Управляемая система RAG, которая разбивает на фрагменты, | Подключает модель к источнику информации; использует | библиотеку на основе LLM для целевой информации | | | встраивает и индексирует файлы. | Поиск файлов, поиск Google и т. д. | извлечение с помощью примеров. | +———————+—————————————+——————————————————-+——————————————————+ | Типичный вариант использования | Чат-бот для базы знаний компании | Ответы на последние события с использованием живых | Извлечение названий, лекарств, дозировок из | | | или руководств. | Результаты поиска Google. | клинические заметки для базы данных. | +———————+—————————————+—————————————+——————————————————-+
Удаление хранилища поиска файлов
Google автоматически удаляет необработанное содержимое вашего файла из своего хранилища файлов через 48 часов, но сохраняет встроенные данные документа, позволяя вам продолжать выполнять поиск по содержимому документа. Если вы решите, что они больше не нужны, вы можете удалить их. Это можно сделать программно, как показано во фрагменте кода ниже.
… … … # удаление хранилищ # Перечислите все хранилища поиска файлов для file_search_store в client.file_search_stores.list(): name = file_search_store.name print(name) # Получите определенное хранилище поиска файлов по имени my_file_search_store = client.file_search_stores.get(name='your_file_search_store_name') # Удалить хранилище поиска файлов client.file_search_stores.delete(name=my_file_search_store.name, config={'force': True})
Краткое содержание
Традиционно создание конвейера RAG требовало сложных этапов: приёма данных, их разделения на фрагменты, генерации вложений, настройки векторных баз данных и внедрения извлечённого контекста в запросы. Новый инструмент поиска файлов от Google абстрагирует все эти задачи, предлагая полностью управляемое сквозное решение RAG, интегрированное непосредственно в API Gemini посредством вызова generateContent .
В этой статье я описал некоторые ключевые функции и преимущества поиска файлов, а затем представил полностью рабочий пример кода на Python, демонстрирующий его использование. В моём примере продемонстрирована загрузка большого PDF-файла (руководства к телефону Samsung) в хранилище поиска файлов и выполнение запроса к нему через модель и API Gemini для точного извлечения нужной информации. Я также показал код, который можно использовать для микроуправления стратегией разбиения документа на фрагменты, если используемая по умолчанию функция поиска файлов не отвечает вашим потребностям. Наконец, чтобы минимизировать затраты, я также привёл фрагмент кода, показывающий, как удалять ненужные хранилища после завершения работы с ними.
Пока я писал это, мне пришло в голову, что на первый взгляд этот инструмент во многом похож на другие продукты Google в этой области, о которых я писал ранее, например, LangExtract и Context Grounding. Однако я объяснил, что у каждого из них есть ключевые отличия, причём File Search — единственная настоящая система RAG из трёх, и подчеркнул эти различия в удобном для чтения табличном формате.
Инструмент поиска файлов Google гораздо шире, чем я смог осветить в этой статье, включая использование метаданных файлов и ссылок. Рекомендую вам изучить онлайн-документацию API Google по ссылке ниже, чтобы получить полное описание всех возможностей поиска файлов.
https://ai.google.dev/gemini-api/docs/file-search#file-search-stores
Источник: towardsdatascience.com
