Багато ділових знань зберігаються в електронній пошті, а потрібна вам частина зазвичай знаходиться у вкладенні: комерційна пропозиція, підписане доповнення, оновлений графік. GroupDocs.Search.Mcp, що працює локально в Docker, відкриває файли електронної пошти та архіви (PST, OST, MSG, EML) і індексує кожне повідомлення та кожне вкладення, тому Claude Desktop, Cursor або Copilot можуть шукати в архіві на місці і точно вказати, з якого вкладення походить збіг:

Індексувати папку пошти. Яке повідомлення згадує підвищення ціни і що саме в ньому сказано?

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

Чому електронна пошта важка для агента?

Тому що архів — це контейнер контейнерів. PST містить папки, папки містять повідомлення, повідомлення містять вкладення, а вкладення — це Word‑файли, PDF‑и та електронні таблиці. Агент з інструментами роботи з файлами бачить один великий бінарний файл. Експорт архіву у окремі файли спочатку працює, але це повільно, дублює конфіденційні дані на диску і потребує повторення, коли архів змінюється. І модель зовсім не може читати PST.

Пошуковий движок сам обробляє вкладеність. Кожне повідомлення і кожне вкладення стають пошуковими елементами, а результат записує і місце розташування контейнера, і місце всередині нього, де знайдено збіг.

Як виглядає збіг всередині вкладення?

Ось що сервер повернув у нашому тесті з трьома EML‑повідомленнями. Фраза «price increase» (підвищення ціни) з’являється лише у Word‑пропозиції, прикріпленій до одного з них; тіло повідомлення просто каже «please find the updated quotation attached».

-> add_to_index {"documentsPath":"mail","indexName":"mail"}
<- Indexed 'mail' into index 'mail': 3 document(s) added, 3 in the index.

-> search {"query":"\"price increase\"","indexName":"mail"}
<- { "documentsFound": 1, "documents": [
     { "filePath": "mail/2026-09-18-re-q3-pricing.eml",
       "innerPath": "quotation-Q-2026-118.docx",
       "occurrences": 1 } ] }

-> get_text_fragments {"query":"\"price increase\"","indexName":"mail"}
<- === mail/2026-09-18-re-q3-pricing.eml → quotation-Q-2026-118.docx
   (1 occurrence(s)) ===
     …Due to raw material costs we announce a price increase
   of 6 percent from 2026-11-01.…

filePath — це повідомлення; innerPath — це вкладення. Агент може відповісти: «повідомлення Re: Q3 pricing від Contoso, у прикріпленій пропозиції Q‑2026‑118: підвищення на 6 % з 1 листопада», і кожна частина цього речення простежується.

mail/2026-09-18-re-q3-pricing.eml          <- filePath
  |- body: "please find the updated quotation attached"
  '- attachment: quotation-Q-2026-118.docx  <- innerPath
        "...we announce a price increase of 6 percent..."

Питання, які працюють з поштою

Звичайна мова запитів застосовується, а кілька шаблонів особливо корисні для листування. Усі вони були перевірені на одному тестовому ящику:

  • «Which message from Fabrikam mentions a delivery delay?»: fabrikam AND delay. Адреси відправників індексуються разом із повідомленням, тому contoso також знайшов рахунок, у тілі якого компанія не згадується.
  • «Find every email that mentions order 77812»: 77812. Цілі числа розглядаються як слова.
  • «Which invoices fall due in October?»: invoice AND content: daterange(2026-10-01 ~~ 2026-10-31). Це знаходить дати, записані в тексті повідомлення, наприклад «due on 2026-10-22». Префікс content: важливий: без нього діапазон дат також збігається з датами, які движок записує для кожного файлу.

Чому локальність важливіша для пошти, ніж для будь‑якого іншого типу даних

Електронна пошта містить конфіденційну інформацію: персональні дані, переговори, HR‑переписки, юридичні поради. Інструменти пошуку, які вимагають завантаження або синхронізації ящика з сервісом, не підходять багатьом командам. Тут архів монтується лише для читання в контейнері на машині, індексується там і шукається там. Єдиний текст, який залишає контейнер, — це те, що агент цитує у відповіді, і навіть це лише при локально розгорнутій моделі.

Для більш щільної конфігурації змонтуйте архів лише для читання і дайте індексу власний том:

docker run --rm -i \
  -v /srv/mail:/data:ro \
  -v /srv/mail-index:/index -e GROUPDOCS_MCP_INDEX_PATH=/index \
  ghcr.io/groupdocs-search/search-net-mcp:latest

Масштабування великого архіву

Архів з десятками тисяч повідомлень індексується без проблем за наявності ліцензії, проте варто підходити до цього свідомо. Індексувати за папками або за роками як окремі шляхи (mail/2025, mail/2026), щоб рік можна було видалити або перебудувати окремо, оскільки движок видаляє цілі індексовані шляхи, а не окремі файли. Тримайте пошту в окремому індексі, відокремленому від контрактів чи звітів, щоб питання про листування не прокручувало все інше. Коли архів зростає, update_index підхоплює нові повідомлення без повторного читання старих.

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

  • У режимі оцінки індекс містить не більше 100 документів, а пошук повертає не більше 10 результатів, і кожне повідомлення та вкладення рахується, тому реальний архів потребує ліцензії. Спочатку викличте get_license_status.
  • Великий PST потребує часу на індексацію: кожне повідомлення та вкладення відкривається. Індексувати один раз, потім використовувати update_index.
  • Скановані вкладення без текстового шару індексуються лише за властивостями файлу; OCR не виконується.
  • Тільки Docker; у Linux додавайте --user "$(id -u):$(id -g)", якщо не користуєтеся вищезгаданою лише‑для‑читання конфігурацією.

FAQ

Чи можу я шукати у PST‑файлі за допомогою AI без Outlook?
Так. Движок читає PST, OST, MSG і EML безпосередньо; Outlook не залучений, і нічого не експортується.

Чи здійснюється пошук всередині вкладень електронної пошти?
Так. Вкладення індексуються як елементи їхнього повідомлення, і збіг у вкладенні повертається з innerPath, що вказує назву вкладення.

Чи мій ящик пошти завантажується кудись?
Ні. Він читається всередині локального контейнера; лише уривки, які агент цитує, потрапляють до вашого провайдера моделі.

Поглибити