מחוזי PDF למאגר נתונים: תכנון פיילוט AI לצוותי רכש

כדי לדעת אילו חוזים מתחדשים בקרוב וכמה התחייבויות יש מול ספק מסוים, לא מספיק להעלות תיקיית PDF לצ׳אט. ב־29 בספטמבר 2026 פרסמה AWS מדריך ארכיטקטורה לניתוח חוזים באמצעות Amazon Quick ו־Amazon Bedrock AgentCore, שמפריד בין חילוץ נתונים, בדיקתם וחיפוש במסמכי המקור. הנה דרך מעשית לתכנן פיילוט כזה לצוות רכש או תפעול בישראל, בלי לבלבל בין תשובה משכנעת לבין חישוב שאפשר לבדוק.

011. הגדירו שאלות לפני שבוחרים שדות

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

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

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

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

022. הכינו את המסמכים ובנו חילוץ עם ראיות

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

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

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

033. הוסיפו סוכן בודק וכללים שאינם תלויים במודל

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

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

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

044. הפרידו בין חיפוש בסעיפים לחישוב במאגר

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

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

SELECT currency, SUM(annual_amount) AS annual_total
FROM contracts
WHERE review_status = 'approved'
  AND annual_amount IS NOT NULL
GROUP BY currency;

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

055. בדקו את הפיילוט לפני שמחברים אותו לעבודה

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

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

לצוות רכש ישראלי, יעד פתיחה טוב הוא דוח חידושים מצומצם עם קישורים לסעיפים, ולא עוזר שמבטיח לענות על כל שאלה משפטית. פתחו אותו תחילה לקריאה בלבד, הגדירו אחראי לטיפול בחריגים והרחיבו את הכיסוי רק אחרי שהבדיקות יציבות. את הוראות ההקמה הספציפיות לשירותי Amazon Quick ו־Amazon Bedrock AgentCore יש לקחת ממדריך AWS המקושר; את אמינות הנתונים העסקיים צריך להוכיח על המסמכים שלכם.