לבנות עוזר AI על המסמכים שלכם בלי לכתוב שורת קוד

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

למה אי אפשר פשוט "להעלות הכל ל-ChatGPT"?

נתחיל מהבעיה, כי אם לא מבינים אותה — לא מבינים למה הפתרון בנוי כמו שהוא בנוי.

למודל שפה (LLM — Large Language Model, המנוע מאחורי ChatGPT/Claude) יש מגבלה שנקראת חלון הקשר (context window): כמות הטקסט שהוא מסוגל "להחזיק בראש" בבת אחת. תחשבו על זה כמו על שולחן עבודה — גם אם הוא גדול, אי אפשר לפרוס עליו 200 מסמכים בו-זמנית. אם תנסו להדביק את כל הארכיון לתוך הצ'אט, או שתחרגו מהמגבלה, או שהמודל "יטבע" בטקסט ויפספס בדיוק את הפסקה הרלוונטית.

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

הפתרון: לא לתת לו לזכור — לתת לו לחפש

הרעיון המרכזי נקרא RAG — Retrieval-Augmented Generation, "ייצור מועשר באחזור". פירוק המילים מסביר הכל: במקום שהמודל ייצֵר תשובה מהזיכרון שלו, אנחנו קודם מאחזרים (retrieve — שולפים) את הקטעים הרלוונטיים מהמסמכים שלכם, ורק אז המודל מייצר (generate) תשובה — מבוססת על מה ששלפנו.

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

איך המערכת יודעת אילו קטעים "רלוונטיים"? כאן נכנס מושג שחייבים להבין: אמבדינג (embedding — הטמעה). כשמחשב קורא משפט, הוא לא מבין מילים — הוא ממיר אותן לרשימה ארוכה של מספרים (וקטור — שורת מספרים) שמייצגת את המשמעות. הקסם: משפטים בעלי משמעות דומה מקבלים מספרים קרובים זה לזה, גם אם המילים שונות לגמרי. "תנאי ביטול ההסכם" ו"מתי אפשר לבטל את החוזה" יקבלו וקטורים שכנים — ולכן כששואלים על אחד, המערכת מוצאת את השני. זה פותר בעיה ש"חיפוש מילים" רגיל (Ctrl+F — חיפוש טקסט מדויק במסמך) נכשל בה לחלוטין, כי Ctrl+F מחפש אותיות זהות, לא משמעות.

ארבעת השלבים — מה באמת קורה מתחת למכסה

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

הנקודה הקריטית בשלב החיתוך (chunking — שבירת מסמך לקטעים קצרים): אם תחתכו גס מדי, כל חתיכה תכיל יותר מדי נושאים והאמבדינג יהפוך ל"מטושטש"; אם תחתכו דק מדי, תאבדו הקשר ותקבלו פסקה חצי-קטועה. נקודת התחלה טובה: בערך 500–800 מילים לחתיכה, עם חפיפה קטנה בין חתיכות שכנות כדי שמשפט שנקטע בגבול לא יאבד.

עכשיו — בלי קוד, בפועל

הנה השלבים הקונקרטיים בכלי "no-code" (כלי שעובדים בו בממשק גרפי, בלי לכתוב תוכנה). אני אשתמש בדוגמה של Custom GPT (גרסת ChatGPT אישית שאתם מגדירים בעצמכם), כי זה הנתיב המהיר ביותר להתחלה, אבל אותו עיקרון תקף ל-Claude Projects, ל-NotebookLM של גוגל או לכלים כמו Dust ו-CustomGPT.ai.

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

2. צרו את העוזר. ב-ChatGPT: לחצו על "Explore GPTs" → "Create". בלשונית "Configure" יש אזור בשם Knowledge — שם מעלים את הקבצים. ברגע שהעליתם, הכלי עושה אוטומטית את ארבעת השלבים הטכניים: חותך לחתיכות, מייצר אמבדינגים, ושומר אותם. זה הקסם של no-code — כל העבודה הטכנית קורית מאחורי הכפתור.

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

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

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

מתי no-code מספיק — ומתי לא

נהיה כנים, כי המטרה שלי שתצליחו ולא שתתאהבו בכלי. הנתיב ה-no-code מצוין ל: בסיסי ידע אישיים, מדריך פנימי לצוות קטן, FAQ לעסק (Frequently Asked Questions — מאגר שאלות נפוצות), מאגר עד כמה מאות מסמכים. הוא לא מתאים כשצריך: עשרות אלפי מסמכים, הרשאות לפי משתמש (מי מורשה לראות מה), או שילוב במערכת קיימת. שם כבר נכנסים פתרונות שדורשים הקמה רצינית יותר — אבל את ההבנה של למה הם בנויים ככה כבר יש לכם, וזה העיקר.

הפינה הקריטית: פרטיות

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

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