כדי לסקור תיקון חוזה עם סוכן AI, אל תדביקו את שני הגרסאות בצ’אט ותשאלו מה שונה. שמרו את שני הקבצים בתיקייה, תנו ל‑GroupDocs.Comparison.Mcp server למצוא את השינויים באופן מקומי, ובקשו מ‑Claude Desktop, Claude Code, Cursor או GitHub Copilot לשפוט אותם:

השוו את הקובץ contract-v1.docx עם contract-v2.docx. רשמו כל שינוי, וסמנו כל דבר שנוגע לתנאי תשלום, אחריות או סיום.

מה הבעיה בלבקש מצ’אטבוט לאתר את השינויים?

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

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

מה צריך להחליט הסוכן, ומה צריך להחליט המנוע?

שאלה מחליט
איזה טקסט שונה בין v1 ל‑v2? המנוע, דרך analyze_changes
באיזה עמוד, באיזה תא בטבלה? המנוע, בכל רשומת שינוי
האם שינוי זה נוגע לתשלום, אחריות או סיום? הסוכן, קורא את רשימת המנוע
האם תנאי של 45 יום מקובל עלינו? אתם
איך נראה הקובץ המסומן? המנוע, דרך compare

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

איך מריצים את הסקירה?

שלב 1: שאלו מה השתנה. שמו את contract-v1.docx ו‑contract-v2.docx בתיקייה שאליה מצביע GROUPDOCS_MCP_STORAGE_PATH, ואז השתמשו במבצע מההתחלה של הפוסט הזה. הסוכן קורא analyze_changes וקורא את הרשימה לפי שלושת הקריטריונים שלכם. מכיוון שכל רשומה נושאת את העמוד ותא הטבלה, ניתן לומר שהלו"ז בתשלום בטבלה בעמוד 4 עבר מ‑30 ל‑45 ימים, ולא רק שמשהו השתנה בעמוד 4.

שלב 2: קבלו את הקובץ המסומן.

עכשיו תנו לי את הגרסה המסומנת שאני יכול לשלוח למחלקת המשפטים.

הסוכן קורא compare, ששומר contract-v1_compared.docx בתיקיית הפלט שלכם. סוקרים פותחים אותו ב‑Word עם ההבדלים מודגשים. אין צורך במשהו נוסף.

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

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

שינוי עיצוב ושינוי ניסוח הם רשומות נפרדות, ולכן הסוכן יכול לומר “זה הפך לבולד” מ‑“זה הפך ל‑45 ימים”.

דוגמת שיחה

מקוצר והמחשה; הניסוח האמיתי תלוי בלקוח ובמודל שלכם.

You:    Compare contract-v1.docx with contract-v2.docx. List every
        change, and flag anything touching payment terms, liability,
        or termination.

Agent:  [calls analyze_changes: contract-v1.docx, contract-v2.docx]

        Flagged: the payment schedule in the table on page 4 changed
        from 30 to 45 days. Other changes are listed below with their
        page and surrounding text.

מה המגבלות של סקירה זו?

  • בדקו את מצב הרישיון לפני שאתם סומכים על תוצאה. במצב הערכה רק העמודים הראשונים (2) מושווים והתוצאה נושאת סימן מים. בחוזה של עשרים עמודים זה מייצר רשימת שינוי קצרה ומרגיעה, שהיא הכישלון החמור ביותר לתהליך הזה. שאלו “מהו מצב הרישיון של שרת ההשוואה?”; הסוכן קורא get_license_status, ו‑"mode": "evaluation" משמעותו שאתם רואים רק שני עמודים של החוזה.
  • הבקשה שלכם איננה מקומית. המסמכים נשארים במחשב שלכם. טקסט הבקשה שלכם, וכל קטע שהסוכן מצטט בחזרה, נשלחים למודל שהלקוח שלכם משתמש בו. להפעלה מקומית מלאה, חברו את השרת עם מודל שמאוחסן באופן מקומי.

שאלות נפוצות

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

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

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

צלילה עמוקה יותר