Часто — ні. Для папки з контрактами, звітами чи електронною поштою AI‑агент з інструментом повнотекстового пошуку знаходить потрібні файли, читає лише відповідні уривки та цитує їх, а індекс працює локально без моделі вбудовування та без векторного сховища. GroupDocs.Search.Mcp надає Claude Desktop, Claude Code, Cursor або Copilot цей інструмент в одному Docker‑команді:

Індексувати цю папку, потім повідомити мені, які контракти згадують штраф за дострокове розірвання, і процитувати пункт.

Крок‑за‑кроком версія з конфігурацією та усуненням проблем знаходиться в документації: Як шукати документи за допомогою AI‑агентів, використовуючи MCP.

Чому всі спочатку звертаються до вбудовувань?

Тому що «генерація з підкріпленням пошуком» з’явилася як рецепт: розбити документи на фрагменти, вбудувати кожен фрагмент, зберегти вектори, вбудувати питання, взяти найближчі фрагменти і вставити їх у підказку. Це працює, і для питань, сформульованих зовсім не так, як у документах, це правильний інструмент. Але це конвеєр, який потребує виклику моделі вбудовування, сховища, налаштування розбиття та повторного вбудовування щоразу, коли документи змінюються. Для «які з моїх 300 контрактів згадують штраф за дострокове розірвання» ця система відповідає на питання, а індекс пошуку відповідає безпосередньо.

Докази наздогнали інтуїцію. Дослідження, опубліковане на arXiv у кінці 2025 року (Keyword search is all you need), надало агенту лише пошук за ключовими словами та регулярними виразами по папці і порівняло його зі стандартним RAG‑конвеєром: понад 90 % показників RAG, без векторної бази даних, і краще підходить для колекцій, які часто змінюються. Агентам‑програмістам вже в практиці показала цей шаблон: вони шукають за допомогою grep, уточнюють і шукають знову.

Що робить агент замість цього?

Три виклики. GroupDocs.Search.Mcp надає вісім інструментів; у циклі потрібні три з них:

user              agent                         Search MCP server
 |  "Which contracts mention a termination penalty?"           |
 |---------------->|                                           |
 |                 |-- add_to_index ------------------------->|  reads the
 |                 |   {"documentsPath":"contracts",           |  files once,
 |                 |    "indexName":"contracts"}               |  stores text
 |                 |<- "5 document(s) added, 5 in the index" --|
 |                 |-- search ------------------------------->|
 |                 |   {"query":"termination AND penalty"}     |
 |                 |<- {"documentsFound":3, "documents":[ ... |  which files
 |                 |-- get_text_fragments ------------------->|
 |                 |   {"query":"\"termination penalty\""}     |
 |                 |<- === contracts/acme-...-agreement.pdf ===|  the passages
 |<- "Two contracts carry one: Acme (3 monthly fees, 12.3),    |
 |    Globex (50% of the remaining fees). Initech excludes it."|

add_to_index читає файли один раз і зберігає текст у іменованому індексі на диску. search повертає відповідні файли у форматі JSON з кількістю входжень. get_text_fragments повертає кожне входження з кількома словами контексту, тому агент цитує пункт замість завантаження всього контракту.

Ось що сервер фактично повернув у нашому тесті, проти п’яти синтетичних контрактів:

-> search {"query":"termination AND penalty","indexName":"contracts"}
<- documentsFound 3: acme-master-services-agreement.pdf,
   globex-consulting-agreement.docx, initech-nda.docx

-> get_text_fragments {"query":"\"termination penalty\"",...}
<- === contracts/acme-master-services-agreement.pdf (1 occurrence(s)) ===
     …a termination penalty of three monthly fees applies, payable
     within 30…
   === contracts/globex-consulting-agreement.docx (1 occurrence(s)) ===
     …Early termination penalty: the Client pays 50 percent of the fees…

Зверніть увагу на третій контракт. NDA Initech відповідав запиту termination AND penalty, бо містить «немає плати і немає штрафу, пов’язаних з розірванням». Уривок саме вказує, чи це збіг, чи лише згадка, і агент, який читає уривки, повідомляє про це. Це обґрунтування: кожна заява у відповіді посилається на файл і речення, яке можна відкрити.

Де кожен підхід переважає?

Конвеєр вбудовування                     Агентний повнотекстовий пошук
-------------------------------------    -------------------------------------
розбити, вбудувати, зберегти у векторному сховищі   add_to_index: локальний повнотекстовий індекс
вбудувати питання, взяти топ‑k фрагментів          агент шукає, уточнює, шукає знову
вставити фрагменти у підказку                      get_text_fragments: цитовані уривки
повторне вбудовування при зміні документів          update_index перечитує зміни
потрібна модель вбудовування та сховище            без викликів моделі, без мережі під час виконання
збігається за змістом; ранжування непрозоре        збігається за словами; кожен збіг пояснюваний

Повнотекстовий пошук втрачає, коли питання і документ не мають спільних слів: «які контракти ризиковані для нас?» не містить ключового слова. Він успішний, коли словник спільний, що описує більшість питань, які люди ставлять щодо своїх документів: назва пункту, продукт, клієнт, номер рахунку, діапазон дат. Коли запит не знаходить, агент пробує renewal OR renews або нечіткий збіг, як би це зробив людина. Сервер допомагає: незакріплений двослівний запит нічого не знаходить у GroupDocs.Search, а порожній результат містить hint, який підказує агенту закрити фразу в лапки.

Який інструмент для якого питання?

The user asks The agent calls
“Індексувати цю папку” add_to_index
“Які файли згадують X?” search
“Що сказано про X?” get_text_fragments
“Файли змінилися, оновити” update_index
“Забути папку drafts” remove_from_index
“Що знаходиться в індексі?” get_index_info
“Створити окремий індекс” create_index
“Чому лише 10 результатів?” get_license_status

Індекс розуміє 82 формати, включаючи PDF, Office, OpenDocument, HTML та архіви електронної пошти (PST, OST, MSG, EML) разом з їхніми вкладеннями.

Як це запустити?

claude mcp add groupdocs-search -- docker run --rm -i \
  -v /path/to/documents:/data ghcr.io/groupdocs-search/search-net-mcp:latest

Cursor, Claude Desktop, VS Code з GitHub Copilot та інші клієнти використовують той самий контейнер у своєму конфігураційному файлі: Реєстрація в AI‑клієнтах. У Linux додайте --user "$(id -u):$(id -g)", щоб контейнер міг записувати індекс у вашу папку. Сервер працює на движку GroupDocs.Search 26.10, новий формат індексу робить індекси меншими і приблизно вдвічі зменшує їх використання пам’яті (release notes).

Чесні обмеження

  • У режимі оцінки індекс містить не більше 100 документів, а пошук повертає не більше 10 результатів; кожна відповідь про це повідомляє. Спочатку викличте get_license_status.
  • Це повнотекстовий пошук, а не семантичний: він збігає слова, а не значення.
  • Без OCR: скановані PDF без текстового шару індексуються лише за властивостями файлу.
  • Доступний лише як Docker‑образ (запакований інструмент перевищує ліміт розміру NuGet).

Питання та відповіді

Чи може Claude шукати мої локальні документи без їх завантаження?
Так. Сервер працює в контейнері на вашому комп’ютері і читає змонтовану папку; лише уривки, які цитує агент, потрапляють до моделі.

Чи це RAG?
Це підкріплене пошуком, але агентне: модель вирішує, що шукати і коли достатньо, використовуючи повнотекстовий індекс замість вбудовувань.

Що відбувається, коли мої документи змінюються?
Попросіть агента оновити. update_index перечитує лише змінені, додані та видалені файли.

Поглиблене вивчення