ארבע תכונות שמסבירות איך מודלים ג'נרטיביים פועלים

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

הוא מייצר תשובה, לא שולף אותה ממגירה

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

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

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

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

אותו מנגנון - שתי תוצאות

הוא יודע הרבה, אבל לא הכול ולא תמיד את מה שצריך

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

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס מקיף לבינה מלאכותית - GenAI Master

לפרטים נוספים לחצו כאן >>

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

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

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

מיקום קובע משקל

גם כשהמידע בפנים, הוא לא תמיד מקבל את אותה תשומת לב

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

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

מחקר מ-2024, שנקרא Lost in the Middle, בדק איך מודלים משתמשים במידע בתוך הקשר ארוך. החוקרים מצאו שהביצועים היו טובים יותר כאשר המידע הרלוונטי הופיע בתחילת הקלט או בסופו, וירדו כאשר אותו מידע היה קבור באמצע.

מחקרים מאוחרים יותר הרחיבו את הבעיה. מחקר מ-2025 בשם Context Length Alone Hurts LLM Performance Despite Perfect Retrieval מצאה שגם כאשר המידע הרלוונטי זמין למודל, עצם הארכת הקלט יכולה לפגוע בביצועים במגוון משימות. מחקר נוסף מ-2025 בדק משימות של הקשר ארוך מעבר להתאמה מילולית פשוטה, וגם הוא מצא ירידה בביצועים ככל שההקשר מתארך.

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

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

ניסוח טוב יותר לא מחליף מקור

הוראות משפיעות על המודל, אבל לא שולטות בו לחלוטין

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

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

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

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

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

הוראה אחת ברורה מנצחת

בדרך כלל זו לא תקלה אחת

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

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

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

איך משתמשים בזה בפועל

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

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

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