Сервіс семантичного пошуку з векторною базою даних Pinecone, розташованою за сервером MCP.

Модель мови може відповідати лише на основі того, що бачила під час навчання. Інженерні стандарти, посібники з політики, специфікації продуктів та внутрішні вікі залишаються для неї недоступними, якщо ці матеріали не надано під час постановки запитання. Описаний тут механізм вирішує цю проблему для збірок у форматі PDF: документи один раз вбудовуються в Pinecone, і будь-який штучний інтелект може отримувати до них доступ через сервер MCP, створений за допомогою SDK FastMCP.

Чому пошук за ключовими словами є недостатнім

Звичайний пошук за ключовими словами здається очевидним рішенням, але люди рідко формулюють запитання саме тими словами, які використовуються в документації, тому релевантні уривки залишаються непоміченими. Словники синонімів та розширення запитів допомагають, проте обидва залежать від відносин між словами, визначених вручну. Жоден з цих методів не розуміє сенсу слів.

Семантичний пошук використовує інший підхід. Як документи, так і запити перетворюються на векторні ембеддинги, які кодують значення, а релевантність оцінюється шляхом порівняння цих векторів за допомогою косинусової схожості — показника того, наскільки близько два вектори спрямовані в одному напрямку в просторі ембеддингів. Вищий бал означає сильніший семантичний зв’язок, тому пов’язані уривки будуть знаходитися, навіть якщо словниковий запас повністю відрізняється. Запит на кшталт «Як рослини перетворюють сонячне світло на енергію?» може вивести текст про хлоропласти та фотосинтез, навіть якщо жоден з цих термінів у ньому не зустрічається.

Два компоненти: база даних векторів та сервер MCP

Система складається з двох частин, які можуть змінюватися незалежно: каналу вхідних даних та сервера MCP. Процес обробки даних виконується один раз за кожен документ. Після цього будь-який підключений агент може неодноразово запитувати ці ж індексовані знання через сервер.

Пайплайн обробки перетворює необроблені PDF-файли на вектори, які можна шукати. Він витягує текст, ділить його на перекриваючіся фрагменти, створює ембеддинги за допомогою Pinecone Inference та записує ці вектори до індексу Pinecone. Створення ембеддингів для великої кількості файлів потребує значних обчислювальних ресурсів, тому простий журнал дозволяє уникнути повторної роботи. Для кожного індексованого файлу зберігається час останнього створення ембеддингу. Під час наступної обробки пайплайн порівнює поточний час змін файлу з збереженим. Змінений документ отримує нові ембеддинги, а незмінений залишається зі своїми існуючими векторами. База даних постійно синхронізується зі змінами в документах, тому не відбувається зайвих викликів для створення ембеддингів.

Сервер MCP, створений на основі FastMCP, отримує запитання мовою природи від агента, вбудовує його, проводить пошук схожості у Pinecone та повертає ті фрагменти, які мають найвищі оцінки. Оскільки інтерфейс є MCP, кілька AI-додатків можуть користуватися одним сервісом пошуку, не знаючи нічого про векторну базу даних чи модель вбудовування, яка стоїть за нею.

Розділення цих двох частин було навмисним. Заміна моделей вбудовування, коригування підходу до розділення на фрагменти чи перебудова векторного індексу можуть відбуватися без впливу на інтерфейс 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

Далі фрагменти тексту перетворюються на ембеддинги. Ембеддинг — це щільне числове представлення тексту, яке кодує його значення. Замість пошуку ключових слів семантичний пошук порівнює вектори, тож пов’язані уривки знаходять один одного незалежно від різного словника. Вектори „кіт“ та „собака“ розташовані близько один до одного у просторі ембеддингів, тоді як „кіт“ та „літак“ знаходяться далеко один від одного, що дозволяє обчислювати схожість математично, а не за точним збігом слів.

Модель ембеддингів тут — це хостований багатомовний е5-large від Pinecone, до якого доступ через API Pinecone Inference. Хостований сервіс означає, що немає окремої моделі машинного навчання, яку потрібно розгортати чи підтримувати, тож код обробки даних може зосереджуватися на роботі з документами, а архітектура залишається простішою.

Цю модель обрали тому, що вона оптимізована для семантичного пошуку та підтримує понад сто мов. Сімейство E5 також розглядає запити та уривки документів як різні типи вхідних даних, що добре підходить для пошуку. Під час індексації фрагменти кодуються як уривки, оскільки саме вони є змістом, який можна шукати. Під час виконання запиту запит користувача кодується як сам запит. Обидва елементи опиняються у одному семантичному просторі, що підвищує шанси знайти потрібний матеріал навіть у разі значних відмінностей у формулюванні.

Щодо пропускної здатності, фрагменти надсилаються до API пакетами по 96 елементів — це найбільший розмір пакета, який наразі дозволяє модель Pinecone Inference для версії multilingual-e5-large. Надсилання багатьох фрагментів за одну заявку зменшує кількість викликів API, краще використовує ресурси та скорочує час індексування порівняно з поступовим надсиланням фрагментів. Готові ембеддинги та їхні метадані потім зберігаються у векторній базі даних Pinecone, готові до пошуку.

embeddings = pc.inference.embed(
    model="multilingual-e5-large",
    inputs=batch,
    parameters={"input_type": "passage"}
)

Сервер MCP для семантичного пошуку

Після індексації документів агентам потрібен спосіб для взаємодії з ними. Замість прямого доступу додатків до бази даних векторів, сервер Model Context Protocol, створений за допомогою FastMCP, виконує функцію проміжного шару. MCP забезпечує додаткам штучного інтелекту єдиний стандартний спосіб виклику інструментів, тож будь-який сумісний клієнт може використовувати функції пошуку без необхідності знання структури бази даних чи моделі ембеддингу. Цей додатковий шар дозволяє повторно використовувати код пошуку, полегшує його обслуговування та зберігає відокремленість від додатків, які ним користуються.

Основною функцією сервера є пошук інформації. Коли агент надсилає запит, сервер ембеддує його за допомогою тієї самої багатомовної моделі e5-large, що використовувалась під час індексації, проводить пошук схожості в індексі Pinecone та повертає найбільш релевантні результати. Використання однієї і тієї самої моделі на обох етапах зберігає фрагменти та запити в одному семантичному просторі, що робить їх порівняння змістовним.

Щоб підвищити якість результатів, інструмент пошуку повертає лише ті результати, у яких коефіцієнт косинусової схожості перевищує 0,82. У експериментах бали вище цього рівня зазвичай свідчили про сильну семантичну відповідність між запитом та фрагментом тексту, тоді як нижчі бали означали, що зв’язок був щонайбільше слабким. Видалення менш корелюючих результатів забезпечує мовним моделям більш релевантний контекст. Запит на кшталт «Як подати звіт про витрати?» може дістатися до правильної сторінки з правилами, навіть якщо документ формулює його інакше. Окрім пошуку, сервер надає інструменти для керування векторною базою даних: додавання векторів, їх видалення та перелік доступних індексів.

Оскільки система призначена для впровадження в корпоративних умовах, безпека є частиною її проектування. Облікові дані надходять з Azure Key Vault, і кожен запит потребує дійсного API-ключа перед виконанням будь-якої операції отримання даних. Конфіденційні деталі інфраструктури залишаються поза досяжністю клієнтських додатків, а доступ до індексованих документів захищений.

results = index.query(
    vector=query_embedding,
    top_k=5,
    include_metadata=True
)

Що показує проєкт щодо використання RAG для внутрішніх документів

Ефективна система семантичного пошуку залежить так само від інженерних рішень, як і від мовних моделей, що лежать в її основі. Стратегія розділення на частини, модель ембеддингу, підхід до групування даних та архітектура пошуку безпосередньо впливають на якість, масштабованість та здатність до підтримки. Розміщення процесів отримання та пошуку даних за допомогою сервера MCP створює модульну систему, яку можна повторно використовувати, легко підтримувати та розширювати у міру змін потреб.

Чинна версія є міцною основою з чіткими можливостями для розвитку. Семантичне розділення інформації, переранжування моделей, гібридний пошук та більш детальні метадані можуть ще більше покращити процес пошуку, зберігаючи при цьому модульну структуру недоторканною. Оскільки генерація з підсиленням пошуком стає звичайною практикою в корпоративних ШІ-системах, надійний семантичний пошук перетворюється на базовий елемент виробничих систем, а поєднання Pinecone Inference зі шаром пошуку MCP є практичним та масштабованим способом створення повторно використовуваного семантичного пошуку.