Служба семантического поиска с векторной базой данных Pinecone, расположенной за сервером MCP.
Служба семантического поиска с возможностью многократного использования: разбивка PDF-файлов на части, хранение эмбеддингов в векторной базе данных Pinecone и предоставление возможности любому агенту выполнять запросы к ним через сервер FastMCP.
Источники: Building a Semantic Search Pipeline with Pinecone and MCP
Модель языка может отвечать только на основе того, что она видела во время обучения. Инженерные стандарты, руководства по политике, технические характеристики продуктов и внутренние вики остаются для неё недоступными, если эти материалы не предоставляются при поступлении вопроса. Описанный здесь процесс обрабатывает подобные ситуации для коллекций PDF: документы один раз встраиваются в Pinecone, и любой ИИ-агент может запрашивать их через сервер MCP, созданный с использованием SDK FastMCP.
Почему поиск по ключевым словам неэффективен
Простой поиск по ключевым словам кажется очевидным решением, но люди редко формулируют вопросы именно теми словами, которые используются в документации, поэтому релевантные фрагменты ускользают. Словари синонимов и расширение запросов помогают, однако оба метода зависят от отношений между словами, заданных вручную. Ни один из них не понимает смысла слов.
Семантический поиск использует иной подход. Документы и запросы преобразуются в векторные представления, которые кодируют смысл, а степень релевантности определяется путем сравнения этих векторов с помощью косинусного сходства — показателя того, насколько близко два вектора направлены в одном направлении в пространстве векторов. Чем выше оценка, тем сильнее семантическая связь, поэтому соответствующие фрагменты текста выводятся даже в случае полной разницы в лексике. Вопрос вроде «Как растения преобразуют солнечный свет в энергию?» может вывести на тексты о хлоропластах и фотосинтезе, даже если ни один из этих терминов в них не упоминается.
Два компонента: векторная база данных и сервер MCP
Система состоит из двух частей, которые могут изменяться независимо: канала ввода данных и сервера MCP. Процесс ввода данных выполняется один раз для каждого документа. После этого любой подключенный агент может неоднократно запрашивать те же индексированные знания через сервер.
Пайплайн обработки преобразует необработанные PDF-файлы в векторы, поддающиеся поиску. Он извлекает текст, делит его на перекрывающиеся фрагменты, генерирует эмбеддинги с помощью Pinecone Inference и записывает векторы в индекс Pinecone. Генерация эмбеддингов для большого количества файлов требует значительных вычислительных ресурсов, поэтому простой журнал операций предотвращает повторную обработку. Для каждого индексированного файла сохраняется время последней генерации эмбеддинга. При следующей обработке пайплайн сравнивает текущее время изменения файла с сохраненным. Документ, который изменился, получает новые эмбеддинги, а неизменный сохраняет свои существующие векторы. База данных постоянно синхронизируется с изменениями в документах, что исключает лишние вызовы для генерации эмбеддингов.
Сервер MCP, построенный на FastMCP, принимает вопрос на естественном языке от агента, встраивает его, выполняет поиск по сходству в Pinecone и возвращает те фрагменты, которые получили наивысший балл. Поскольку интерфейс представляет собой MCP, несколько ИИ-приложений могут использовать одну и ту же службу поиска, не зная ничего о векторной базе данных или модели встраивания, стоящей за ней.
Разделение этих двух компонентов было сделано намеренно. Замена моделей встраивания, корректировка способа разбиения на фрагменты или пересоздание векторного индекса могут осуществляться без вмешательства в интерфейс MCP или в любые агенты, которые от него зависят.
Создание системы генерации встраиваемых данных и разбиения на фрагменты
PDF-файлы создаются для человеческого восприятия, а не для поиска машинами, поэтому сначала они должны преобразоваться в формат, отражающий смысл содержимого. Процесс начинается с извлечения текста из каждого файла с помощью библиотеки pypdf в Python: страницы читаются по одной, а полученные данные объединяются в одну строку для удобства дальнейшей обработки. Система поддерживает как отдельные файлы, так и целые папки, что позволяет индексировать новые наборы документов без изменений в механизме поиска.
Выбор способа разбиения на части
После извлечения текста документ разделяется на более мелкие части, называемые фрагментами, и это решение оказалось одним из самых важных на всем этапе обработки. У моделей эмбеддингов есть фиксированные окна контекста, что исключает возможность представления всего документа в виде одного вектора. Даже если документ помещается в эти рамки, единый эмбеддинг всего файла даёт общее, размытое представление, поскольку несколько не связанных между собой тем смешиваются, что снижает точность поиска.
Каждый документ разделяется на фиксированных по размеру фрагменты, которые перекрываются друг с другом, что позволяет каждому эмбеддингу представлять более узкий участок текста. Выбор размера фрагментов — это поиск баланса между контекстом и специфичностью. Маленькие фрагменты обычно обеспечивают более точные результаты, поскольку каждый эмбеддинг отражает более узкую идею, однако они генерируют больше векторов и увеличивают время индексации и объем хранилища. Большие фрагменты сохраняют больше окружающего контекста и сокращают количество векторов, но каждый эмбеддинг охватывает более широкий диапазон информации, что может снизить точность. Семантическое или основанное на предложениях разделение на фрагменты существует как более сложная альтернатива, однако простое разделение на фиксированные по размеру фрагменты оказалось простым и эффективным базовым решением для универсального поиска.
chunks = [
text[i:i+500]
for i in range(0, len(text), 450)
]
/*
Fixed-size overlapping chunk generation used during document ingestion.
A chunk length of 500 characters and a stride of 450 characters preserve
contextual continuity while maintaining semantic specificity.
*/
Эмбеддинги с Pinecone
Далее фрагменты текста преобразуются в эмбеддинги. Эмбеддинг — это плотное числовое представление текста, кодирующее его смысл. Вместо поиска по ключевым словам семантический поиск сравнивает векторы, поэтому связанные фрагменты текста находятся друг с другом, несмотря на различия в лексике. Векторы слов «кошка» и «собака» располагаются рядом друг от друга в пространстве эмбеддингов, тогда как векторы «кошка» и «самолет» находятся далеко друг от друга, что позволяет вычислять степень сходства с помощью математических методов, а не поиска точного совпадения слов.
Модель эмбеддингов здесь — это многоязычная модель Pinecone multilingual-e5-large, размещенная на серверах, к которой можно получить доступ через API Pinecone Inference. Благодаря использованию хостингового сервиса не требуется развертывать или обслуживать отдельную модель машинного обучения, поэтому код для обработки данных может сосредоточиться исключительно на работе с документами, а архитектура остается проще.
Эта модель была выбрана потому, что она оптимизирована для семантического поиска и поддерживает более ста языков. Семейство E5 также рассматривает запросы и фрагменты документов как разные типы входных данных, что способствует эффективному поиску. Во время индексации фрагменты встраиваются в виде текстовых отрывков, поскольку именно они являются содержимым, подлежащим поиску. При выполнении запроса вопрос пользователя встраивается в виде самого запроса. Оба элемента оказываются в одном семантическом пространстве, что повышает вероятность нахождения нужного материала даже при значительных различиях в формулировках.
Чтобы повысить пропускную способность, данные отправляются в API пакетами по 96 единиц — это максимальный размер пакета, разрешенный в настоящее время для модели multilingual-e5-large в Pinecone Inference. Отправка большого количества данных за один запрос сокращает количество вызовов API, позволяет более эффективно использовать ресурсы и ускоряет процесс индексации по сравнению с постепенной обработкой данных пакетами. Готовые векторные представления и их метаданные затем хранятся в векторной базе данных Pinecone для последующего поиска.
embeddings = pc.inference.embed(
model="multilingual-e5-large",
inputs=batch,
parameters={"input_type": "passage"}
)
Сервер MCP для семантического поиска
После индексации документов агентам необходим способ взаимодействия с ними. Вместо прямого доступа приложений к векторной базе данных её обеспечивает сервер Model Context Protocol, построенный с использованием FastMCP. MCP предоставляет ИИ-приложениям единый стандартный способ вызова инструментов, что позволяет любому совместимому клиенту использовать функции поиска без необходимости знания структуры базы данных или модели вкладки. Дополнительный слой обеспечивает возможность повторного использования кода поиска, его простоту обслуживания и отделение от приложений, которые им пользуются.
Основная задача сервера — поиск информации. Когда агент отправляет вопрос, сервер вкладывает его в формат, используя ту же модель multilingual-e5-large, что и при индексации, выполняет поиск похожести в индексе Pinecone и возвращает наиболее релевантные результаты. Использование одной и той же модели на обоих этапах позволяет сохранять результаты поиска и запросы в одном семантическом пространстве, что делает их сравнение значимым.
Для повышения качества результатов поисковый инструмент возвращает только те результаты, у которых коэффициент косинусного сходства превышает 0,82. В экспериментах значения выше этого порога обычно указывали на сильное семантическое совпадение между запросом и фрагментом текста, тогда как более низкие значения свидетельствовали о косвенной связи. Исключение менее значимых результатов обеспечивает языковым моделям более релевантный контекст. Вопрос вроде «Как подать отчет о расходах?» может привести к нужной странице с правилами, даже если в документе формулировки отличаются. Помимо поиска, сервер предоставляет инструменты для управления векторной базой данных: вставка векторов, их удаление и отображение доступных индексов.
Поскольку система предназначена для использования в крупных предприятиях, безопасность является неотъемлемой частью её проектирования. Учетные данные поступают из Azure Key Vault, и каждый запрос требует действительного API-ключа перед выполнением любых операций по получению данных. Конфиденциальная информация об инфраструктуре не попадает в клиентские приложения, а доступ к индексированным документам защищен.
results = index.query(
vector=query_embedding,
top_k=5,
include_metadata=True
)
Что показывает проект о технологии RAG для внутренних документов
Эффективная система семантического поиска зависит не менее сильно от инженерных решений, чем от используемых под ней языковых моделей. Стратегия разбиения текста на фрагменты, модель вкладкирования, подход к группировке запросов и архитектура поиска напрямую влияют на качество, масштабируемость и возможности технического обслуживания. Размещение процессов загрузки данных и поиска за пределами основного сервера позволяет создать модульную систему, которая может быть повторно использована, легко обслуживается и удобна для расширения по мере изменения потребностей.
Текущая версия представляет собой прочную основу с явным потенциалом для дальнейшего развития. Семантическое разделение данных, переранжирование моделей, гибридный поиск и более подробные метаданные могут ещё больше улучшить процесс поиска, сохраняя при этом модульную структуру. По мере того как генерация с усилением поиска становится обычной практикой в корпоративных ИИ-системах, надёжный семантический поиск превращается в основной элемент производственных систем, а сочетание Pinecone Inference с слоем поиска MCP — это практичный и масштабируемый способ создания повторно используемого семантического поиска.
Связанные материалы
- Семантический поиск против векторного поиска: в чём разница и какова роль RAG и Azure AI Search: объяснение поиска по ключевым словам, векторному, семантическому и гибридному методам на примерах политик отказа и инцидентов, а также взаимосвязь Azure AI Search, Semantic Kernel и RAG.