ایمیل‌ها منبع زیادی از دانش تجاری هستند و بخشی که به آن نیاز دارید معمولاً در یک پیوست قرار دارد: پیش‌نویس قیمت، اصلاحیه امضا شده، برنامه زمان‌بندی بازنگری‌شده. GroupDocs.Search.Mcp که به‌صورت محلی در Docker اجرا می‌شود، فایل‌ها و آرشیوهای ایمیل (PST، OST، MSG، EML) را باز می‌کند و هر پیام و هر پیوست را ایندکس می‌نماید، به‌طوری که Claude Desktop، Cursor یا Copilot بتوانند یک آرشیو را در محل جستجو کنند و دقیقاً بگویند تطبیق از کدام پیوست آمده است:

فهرست پوشه ایمیل. کدام پیام به «افزایش قیمت» اشاره دارد و دقیقاً چه می‌گوید؟

نسخه گام‌به‌گام با پیکربندی و عیب‌یابی در مستندات موجود است: چگونه آرشیوهای ایمیل و پیوست‌ها را به‌صورت محلی با یک عامل هوش مصنوعی جستجو کنیم.

چرا ایمیل برای یک عامل دشوار است؟

چون یک آرشیو، یک مخزن از مخازن است. یک PST شامل پوشه‌هاست، پوشه‌ها شامل پیام‌ها، پیام‌ها شامل پیوست‌ها، و پیوست‌ها خود فایل‌های Word، PDF و صفحات‌گسترده هستند. یک عامل با ابزارهای فایل، یک فایل باینری بزرگ می‌بیند. استخراج آرشیو به فایل‌های جداگانه ابتدا کار می‌کند، اما کند است، داده‌های حساس را روی دیسک تکثیر می‌کند و وقتی آرشیو تغییر می‌کند باید دوباره انجام شود. همچنین یک مدل نمی‌تواند به‌طور مستقیم یک PST را بخواند.

موتور جستجو خود به‌خود تو در تویی را مدیریت می‌کند. هر پیام و هر پیوست به یک آیتم جستجوپذیر تبدیل می‌شود و نتیجه هر دو مکان‌ٔ مخزن و مکان داخل آن را ثبت می‌کند.

یک تطبیق داخل پیوست چگونه نمایش داده می‌شود؟

در تست ما با سه پیام EML، سرور خروجی زیر را برگرداند. عبارت «افزایش قیمت» فقط در پیش‌نویس Word پیوست‌شده به یکی از آن‌ها ظاهر می‌شود؛ بدنهٔ پیام فقط می‌گوید «لطفاً پیش‌نویس به‌روزشده را پیوست می‌کنیم».

-> 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: افزایش ۶ درصدی از ۱ نوامبر»، و هر بخش از این جمله قابل ردیابی است.

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..."

پرسش‌هایی که روی ایمیل کار می‌کنند

زبان پرس‌و‌جو معمولی اعمال می‌شود و چند الگو به‌ویژه برای مکاتبه مفید هستند. همه این‌ها در همان صندوق‌پست تست بررسی شدند:

  • «کدام پیام از Fabrikam به تأخیر تحویل اشاره دارد؟»: fabrikam AND delay. آدرس‌های فرستنده همراه با پیام ایندکس می‌شوند، بنابراین contoso نیز یک فاکتور را یافت که متن آن هرگز نام شرکت را نیاورده بود.
  • «تمام ایمیل‌هایی که به سفارش 77812 اشاره می‌کنند را پیدا کنید»: 77812. اعداد کامل به‌عنوان کلمه در نظر گرفته می‌شوند.
  • «کدام فاکتورها در ماه اکتبر سررسید دارند؟»: invoice AND content: daterange(2026-10-01 ~~ 2026-10-31). این الگو تاریخ‌های نوشته‌شده در متن پیام را می‌یابد، مثلاً «سررسید در 2026-10-22». پیشوند content: مهم است: بدون آن، بازهٔ تاریخی همچنین تاریخ‌های ثبت‌شده توسط موتور برای هر فایل را می‌گیرد.

چرا محلی بودن برای ایمیل مهم‌تر از سایر موارد است

ایمیل جایی است که مواد حساس ذخیره می‌شود: داده‌های شخصی، مذاکرات، رشته‌های منابع انسانی، مشاوره‌های حقوقی. ابزارهای جستجو که نیاز به بارگذاری یا همگام‌سازی صندوق‌پست با سرویس دارند، برای بسیاری از تیم‌ها غیرقابل‌قبول هستند. در اینجا آرشیو به‌صورت فقط‑خواندنی در یک کانتینر روی ماشین سوار می‌شود، در همانجا ایندکس می‌شود و جستجو می‌شود. تنها متنی که خارج می‌شود، همان متنی است که عامل در پاسخ خود می‌نقلند و حتی آن هم فقط با یک مدل میزبانی‑محلی است.

برای یک تنظیمات فشرده‌تر، آرشیو را فقط‑خواندنی سوار کنید و به ایندکس یک حجم جداگانه بدهید:

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 پیام‌های جدید را بدون خواندن مجدد قدیمی‌ها می‌گیرد.

محدودیت‌های صادقانه

  • در حالت ارزیابی یک ایندکس حداکثر ۱۰۰ سند را نگه می‌دارد و جستجو حداکثر ۱۰ نتیجه برمی‌گرداند، و هر پیام و پیوست حساب می‌شود، بنابراین یک آرشیو واقعی به لایسنس نیاز دارد. ابتدا get_license_status را فراخوانی کنید.
  • یک PST بزرگ زمان‌بر است: هر پیام و هر پیوست باز می‌شود. یک‌بار ایندکس کنید، سپس update_index را اجرا کنید.
  • پیوست‌های اسکن‌شده بدون لایهٔ متنی فقط بر اساس ویژگی‌های فایل ایندکس می‌شوند؛ OCR وجود ندارد.
  • فقط Docker؛ در لینوکس --user "$(id -u):$(id -g)" را اضافه کنید مگر اینکه از تنظیمات فقط‑خواندنی بالا استفاده کنید.

پرسش‌های متداول

آیا می‌توانم یک فایل PST را با هوش مصنوعی بدون Outlook جستجو کنم؟
بله. موتور مستقیماً PST، OST، MSG و EML را می‌خواند؛ Outlook درگیر نیست و هیچ‌چیزی صادر نمی‌شود.

آیا داخل پیوست‌های ایمیل جستجو می‌کند؟
بله. پیوست‌ها به‌عنوان آیتم‌های پیام ایندکس می‌شوند و یک تطبیق داخل یکی از آن‌ها همراه با innerPath که نام پیوست را نشان می‌دهد برمی‌گردد.

آیا صندوق‌پست من در جایی بارگذاری می‌شود؟
خیر. داخل یک کانتینر محلی خوانده می‌شود؛ تنها بخش‌هایی که عامل نقل می‌کند به ارائه‌دهندهٔ مدل شما می‌رسند.

عمیق‌تر شوید