כל שיחה חדשה מתחילה עם סוכן ששכח את המסמכים שלך. הוא יכול לקרוא אותם מחדש, על חשבון זמן והקשר, או שהוא יכול להתייעץ עם משהו שזוכר. GroupDocs.Search.Mcp שומר אינדקס טקסט מלא בשם על הדיסק, מקומית, שמשרוד בין סשנים והפעלות של המכולה, כך ש‑Claude Desktop, Cursor או Copilot מתחילים כל סשן עם המסמכים של הפרויקט כבר ניתנים לחיפוש ומרעננים אותם בקריאה אחת כאשר קבצים משתנים:

ערכתי כמה חוזים. רענן את אינדקס החוזים, ואז אמור לי אילו חוזים מזכירים קנס עכשיו.

הגרסה צעד‑אחר‑צעד עם תצורה ופתרון בעיות נמצאת בתיעוד: איך לשמור על אינדקס מסמכים עדכני כאשר קבצים משתנים.

מה משמעות “זיכרון” עבור סוכן?

בפועל, שני דברים: מצב שממשיך להתקיים מחוץ לשיחה, ודרך זולה לשמור על מצב זה נכון. היסטוריית הצ’אט נכשלת בשניהם: היא מסתיימת עם הסשן, ושום דבר לא מעדכן אותה כאשר מסמך משתנה. אינדקס חיפוש הוא התאמה טובה יותר למסמכים. הוא נמצא על הדיסק לידם, הוא משיב על “אילו קבצים אומרים X” מבלי לטעון אותם, וניתן לרענן אותו באופן אינקרמנטלי.

session 1    add_to_index --> index "contracts" --+
                                                 |  kept on disk in
session 2    search, get_text_fragments <--------+  /data/.groupdocs-search-
             (nothing is re-read)                    index/contracts
files edit   update_index --> re-reads changed, added, deleted files only
new project  create_index {"indexName":"legal-2026"} --> a separate index

איך רענון עובד?

update_index משווה את האינדקס עם הקבצים על הדיסק וקורא מחדש רק את מה שהשתנה. הנה מה שהשרת החזיר בבדיקה שלנו, אחרי שחוזה אחד קיבל סעיף קנס שנוסף בין שתי קריאות:

-> get_index_info {"indexName":"contracts"}
<- { "documentCount": 5, "indexedPaths": [ "contracts" ],
     "documentsWithErrors": [], "status": "Ready" }

-> update_index {"indexName":"contracts"}
<- Index 'contracts' updated: 0 added, 1 updated, 0 removed;
   5 document(s) in the index.

-> search {"query":"penalty","indexName":"contracts"}
<- documentsFound 3, including the edited initech-nda.docx

הספירות אומרות לך מה קרה: קובץ אחד נקרא מחדש, שום דבר אחר לא נגע. קבצים שנמחקו נעלמים באותה קריאה.

למה אינדקס אחד לכל פרויקט?

כיוון שמאגרים נפרדים ראויים לתשובות נפרדות. שאלה על חוזים של השנה הזו לא צריכה להציג טיוטות של השנה שעברה, ומסמכי לקוח לא צריכים להתערבב עם של לקוח אחר. שמות אינדקסים זולים:

-> create_index {"indexName":"legal-2026"}
<- Index 'legal-2026' created. Add documents with add_to_index
   (indexName: 'legal-2026').

כל אינדקס הוא תיקייה תחת /data/.groupdocs-search-index, ו‑get_index_info ללא שם מציג את כולם. כמעט ולא תצטרך להשתמש ב‑create_index במפורש, מכיוון ש‑add_to_index יוצר אינדקס בפעם הראשונה שבה הוא משמש, אך מתן שם בכוונה הוא מה שהופך “אינדקס” ל"זיכרון של הפרויקט הזה".

הכלל האחד לגבי הסרה

המנוע מסיר נתיבים שנוספו, ולא קבצים בודדים בתוכם. השרת מודיע על כך במפורש כשאתה מנסה:

-> remove_from_index {"documentPath":"contracts/hooli-supply-terms.txt",...}
<- Removal failed for 'contracts/hooli-supply-terms.txt':
   'contracts/hooli-supply-terms.txt' is inside the indexed folder
   'contracts'. GroupDocs.Search removes whole indexed paths only: ...

לכן תכנן זאת: אם אתה מצפה להסיר חלק ממאגר מאוחר יותר, כגון שנה, לקוח או הטיוטות, אינדקס את החלקים האלה כנתיבים נפרדים (contracts/2025, contracts/2026) וכל אחד מהם ניתן להסרה בנפרד. מחיקת קובץ מהדיסק והרצת update_index גם מסירים אותו.

שמירה על עדכניות ללא בקשה

create_index (optional)
      |
      v
add_to_index ---> search ---> get_text_fragments
      ^              ^
      |              |  get_index_info: counts, paths, status
update_index  (files changed on disk)
      |
remove_from_index  (only a path that was given to add_to_index)

שלוש דרכים מעשיות להפוך את הרענון לאוטומטי:

  1. בהוראות של הסוכן. שורה ב‑CLAUDE.md או AGENTS.md, “קרא update_index עבור אינדקס הפרויקט הזה לפני שמגיבים אם קבצים עשויים להשתנות”, גורמת לסוכן לבצע זאת בתחילת הסשן.
  2. בלו"ז קבוע. כל אוטומציה תומכת MCP יכולה לקרוא ל‑update_index בלילה; כאשר השתנו מעט, הקריאה מהירה.
  3. לאחר העתקה גורפת. קריאה אחת תופסת כל קובץ שנוסף.

האינדקסים גם שורדים עדכונים: אינדקסים שנבנו על ידי GroupDocs.Search 22.7 עד 26.8 מומרצים בפעם הראשונה שבה הם משמשים, עם גיבוי שנשמר לידם.

מה הסוכן מחליט, ומה האינדקס עושה

הסוכן מחליט האינדקס עושה
לאיזה אינדקס שאלה שייכת שומר כל אינדקס בשם בתיקייה משלו
מתי קבצים עשויים להשתנות קורא מחדש רק קבצים שהשתנו, נוספו ונמחקו
אילו מילים לחפש, ואילו וריאנטים לנסות מתאים מילים, ביטויים, טווחים; מדווח על המונחים שמצא
כמה הקשר לצטט מחזיר קטעים עם מספר המילים המבוקש סביבם
מה לומר לך שום דבר: הוא מחזיר ספירות, נתיבים וטקסט, לעולם לא מסקנות

הפיצול מכוון. השיפוט נשאר עם המודל, והעובדות שהוא מתבסס עליהן מגיעות מכלי שהפלט שלו ניתן לבחינה.

מגבלות כנות

  • במצב הערכה אינדקס מכיל לכל היותר 100 מסמכים וחיפוש מחזיר לכל היותר 10. קרא get_license_status לפני שאתה סומך על אינדקס כמקור האמת.
  • האינדקס נשמר רק אם /data (או נפח האינדקס) הוא תיקייה מותקנת במארח; אחרת הוא נעלם עם המכולה.
  • האינדקס מכיל את הטקסט של המסמכים: יש להגן עליו ולהשמידו כמו על המסמכים.
  • רק Docker; בלינוקס הוסף --user "$(id -u):$(id -g)" כדי שהקונטיינר יוכל לכתוב לאינדקס.

שאלות נפוצות

האם הסוכן זוכר את המסמכים שלי בין סשנים?
עם אינדקס מתמשך, כן: האינדקס נשאר על הדיסק והסשן הבא מחפש בו מבלי לקרוא משהו מחדש.

האם אני צריך לבנות מחדש את האינדקס כאשר קבצים משתנים?
לא. update_index קורא מחדש רק קבצים שהשתנו, נוספו ונמחקו.

האם אני יכול לשמור את האינדקס נפרד ממסמכים לקריאה בלבד?
כן. טען את המסמכים במצב קריאה בלבד, טען תיקייה ניתנת לכתיבה ב‑/index, וקבע GROUPDOCS_MCP_INDEX_PATH=/index.

להעמיק יותר