اغلب، نه. برای یک پوشه حاوی قراردادها، گزارش‌ها یا ایمیل‌ها، یک عامل هوش مصنوعی با ابزار جستجوی متن کامل فایل‌های مناسب را پیدا می‌کند، فقط بخش‌های مطابق را می‌خواند و استناد می‌کند، و ایندکس به‌صورت محلی اجرا می‌شود بدون مدل تعبیه و بدون ذخیره‌ساز برداری. GroupDocs.Search.Mcp این ابزار را در یک فرمان Docker به Claude Desktop، Claude Code، Cursor یا Copilot می‌دهد:

پوشه قراردادها را ایندکس کنید، سپس به من بگویید کدام قراردادها جریمه خاتمه دارند و بند مربوطه را نقل قول کنید.

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

چرا همه ابتدا به تعبیه‌ها (embeddings) روی می‌آورند؟

به این دلیل که «تولید تقویت‌شده با بازیابی» به‌عنوان یک دستورالعمل ظاهر شد: اسناد را به بخش‌های کوچک تقسیم کنید، هر بخش را تعبیه کنید، بردارها را ذخیره کنید، سؤال را تعبیه کنید، نزدیک‌ترین بخش‌ها را بگیرید و در پرامپت بچسبانید. این کار می‌کند و برای سؤال‌هایی که شبیه اسناد نیستند ابزار مناسبی است. اما این یک خط لوله است که نیاز به یک مدل تعبیه برای فراخوانی، یک ذخیره‌ساز برای اجرا، تنظیم بخش‌بندی و یک کار دوباره‑تعبیه هر بار که اسناد تغییر می‌کنند دارد. برای «کدام یک از ۳۰۰ قرارداد من جریمه خاتمه دارند»، این سازوکار پاسخی می‌دهد که یک ایندکس جستجو مستقیماً می‌تواند بدهد.

شواهد با شهود همگام شده‌اند. مطالعه‌ای که در اواخر ۲۰۲۵ در arXiv منتشر شد (جستجوی کلیدواژه همه‌چیز است) به یک عامل چیزی جز جستجوی کلیدواژه و regex روی یک پوشه نداد و آن را در مقابل یک خط لوله استاندارد RAG سنجید: بیش از ۹۰٪ از امتیازهای 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 اینیتک termination AND penalty را مطابقت داد زیرا می‌گوید «هیچ هزینه‌ای و هیچ جریمه‌ای مرتبط با خاتمه وجود ندارد». این بخش است که تفاوت بین مطابقت و اشاره را نشان می‌دهد، و عاملی که این بخش‌ها را می‌خواند این را می‌گوید. این همان استوارسازی (grounding) است: هر ادعایی در پاسخ به یک فایل و یک جمله‌ای که می‌توانید باز کنید اشاره دارد.

هر رویکرد کجا برتری دارد؟

خط لوله تعبیه                       جستجوی متن کامل عامل‌محور
-------------------------------------    -------------------------------------
تقسیم، تعبیه، ذخیره در یک ذخیره‌ساز برداری    add_to_index: یک ایندکس متن کامل محلی
سؤال را تعبیه کنید، بالاترین k بخش را بگیرید    عامل جستجو می‌کند، اصلاح می‌کند، دوباره جستجو می‌کند
بخش‌ها را در پرامپت بچسبانید         get_text_fragments: بخش‌های نقل‌قول‌شده
دوباره تعبیه کنید وقتی اسناد تغییر می‌کنند           update_index دوباره می‌خواند آنچه تغییر کرده
به یک مدل تعبیه و یک ذخیره‌ساز نیاز دارد     بدون فراخوانی مدل، بدون شبکه در زمان اجرا
معانی را مطابقت می‌دهد؛ رتبه‌بندی مبهم است       کلمات را مطابقت می‌دهد؛ هر نتیجه قابل توضیح است

جستجوی متن کامل زمانی که سؤال و سند هیچ کلمه‌ای مشترک ندارند، شکست می‌خورد: «کدام قراردادها برای ما پرخطر هستند؟» هیچ کلیدواژه‌ای ندارد. وقتی واژگان مشترک هستند، برنده می‌شود، که این توصیف‌کننده اکثر سؤال‌هایی است که مردم درباره اسناد خود می‌پرسند: نام یک بند، یک محصول، یک مشتری، شماره فاکتور، بازه زمانی. وقتی یک پرسش ناقص باشد، عامل renewal OR renews یا یک تطبیق مبهم را امتحان می‌کند، همان‌طور که یک شخص انجام می‌دهد. سرور کمک می‌کند: یک پرسش دوکلمه‌ای بدون نقل‌قول در GroupDocs.Search هیچ چیزی پیدا نمی‌کند، و نتیجه خالی یک hint دارد که به عامل می‌گوید عبارت را نقل قول کند.

برای هر سؤال از کدام ابزار استفاده کنیم؟

کاربر می‌پرسد عامل فراخوانی می‌کند
“این پوشه را ایندکس کنید” add_to_index
“کدام فایل‌ها X را ذکر می‌کنند؟” search
“در مورد X چه می‌گوید؟” get_text_fragments
“فایل‌ها تغییر کردند، تازه‌سازی” update_index
“پوشه پیش‌نویس‌ها را فراموش کنید” remove_from_index
“چه چیزی در ایندکس است؟” get_index_info
“یک ایندکس جداگانه شروع کنید” create_index
“چرا فقط ۱۰ نتیجه؟” get_license_status

این ایندکس ۸۲ فرمت را می‌فهمد، از جمله 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 و سایر مشتریان از همان کانتینر در فایل پیکربندی خود استفاده می‌کنند: ثبت‌نام در مشتریان هوش مصنوعی. در لینوکس --user "$(id -u):$(id -g)" را اضافه کنید تا کانتینر بتواند ایندکس را در پوشه شما بنویسد. سرور از موتور GroupDocs.Search نسخه ۲۶.۱۰ استفاده می‌کند، که قالب ایندکس جدید آن ایندکس‌ها را کوچکتر می‌کند و تقریباً مصرف حافظه را نصف می‌کند (یادداشت‌های انتشار).

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

  • در حالت ارزیابی، یک ایندکس حداکثر ۱۰۰ سند را نگه می‌دارد و جستجو حداکثر ۱۰ نتیجه برمی‌گرداند؛ هر پاسخ این را می‌گوید. ابتدا get_license_status را فراخوانی کنید.
  • این یک جستجوی متن کامل است، نه جستجوی معنایی: کلمات را مطابقت می‌دهد، نه معنا.
  • بدون OCR: PDFهای اسکن‌شده بدون لایه متن فقط بر اساس ویژگی‌های فایل ایندکس می‌شوند.
  • فقط به‌صورت تصویر Docker عرضه می‌شود (ابزار بسته‌بندی‌شده از محدودیت اندازه NuGet فراتر رفته است).

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

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

آیا این RAG است؟
این بازیابی‑تقویت‌شده است، اما عامل‌محور: مدل تصمیم می‌گیرد چه چیزی را جستجو کند و چه زمانی کافی است، با استفاده از یک ایندکس متن کامل به‌جای تعبیه‌ها.

چه اتفاقی می‌افتد وقتی اسناد من تغییر می‌کنند؟
از عامل بخواهید تازه‌سازی کند. update_index فقط فایل‌های تغییر یافته، اضافه‌شده و حذف‌شده را دوباره می‌خواند.

عمیق‌تر بروید