מהי בינה מלאכותית, באמת?

פתח דבר: מה בדיוק השתנה?#

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

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

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

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

„בינה מלאכותית” היא שם של תחום, לא שם של מוצר#

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

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

יש כאן שלוש נקודות חשובות:

1. לא כל AI מייצרת טקסט. מערכת שמזהה פגם במוצר מתוך צילום, מערכת המנבאת ביקוש, או מערכת הממליצה על מסלול יכולות להיות מערכות AI גם אם לעולם אינן „משוחחות”.
2. לא כל AI לומדת מדוגמאות. לאורך ההיסטוריה נבנו גם מערכות AI המבוססות על סמלים, חוקים וידע מפורש של מומחים. למידת מכונה היא גישה מרכזית ל־AI, לא ההגדרה היחידה שלה [2].
3. המודל אינו בהכרח כל המערכת. מוצר שבו משתמשים יכול להכיל מודל, מסד נתונים, מנוע חיפוש, כללי הרשאות, כלי חישוב, חיבורי API ואישור אנושי. היכולת שהמשתמש חווה נוצרת מהשילוב ביניהם.

דוגמה: שלושה רכיבים שנראים כמו „אותה בינה”#

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

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

אלגוריתם, תוכנה, אוטומציה ו־AI: ארבע שאלות שונות#

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

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

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

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

AI מתייחסת לסוגי מנגנוני ההסקה והיכולות שמאפשרים למערכת לייצר פלט מתוך קלט. במערכות רבות של למידת מכונה, הדפוסים אינם מתוכנתים אחד־אחד אלא נלמדים מנתונים. אבל גם גישות סימבוליות — הפועלות על ידע וכללים מפורשים — נכללות בעולם ה־AI. לכן הניגוד „אוטומציה = חוקים, AI = למידה” הוא קיצור פופולרי אך לא מדויק [1][2].

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

אותה בעיה, שלוש דרכים לפתור אותה#

נחזור לחשבונית שהגיעה במייל. לצורך הלימוד נגדיר שלוש משימות נפרדות:

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

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

דרך א': חוקים מפורשים — Rule-based automation#

מפתח יכול לכתוב כלל:

אם שורת הנושא מכילה „חשבונית” ויש קובץ PDF מצורף, שמור אותו בתיקיית „חשבוניות לבדיקה”. אחרת, השאר אותו בתיבת הדואר.

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

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

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

דרך ב': מודל סיווג שנלמד מדוגמאות — Machine learning#

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

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

חשוב להבחין בין שלושה שלבים:

1. אימון (Training): חשיפת המודל לדוגמאות ושינוי הפרמטרים שלו כדי לצמצם שגיאות בהתאם ליעד האימון.
2. הערכה (Evaluation): בדיקה על דוגמאות שלא שימשו ללימוד עצמו, כדי להעריך אם היכולת עובדת מעבר למה שכבר נראה.
3. הסקה (Inference): שימוש במודל המאומן כדי להפיק תחזית עבור קלט חדש. ברוב המערכות הפרמטרים אינם משתנים בכל פעם שמבקשים תחזית [2].

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

דרך ג': מודל גנרטיבי שמפיק מידע מובנה#

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

{
  "document_type": "invoice",
  "supplier": "אורן תקשורת",
  "invoice_number": "48621",
  "amount": 1849.00,
  "currency": "ILS",
  "due_date": "2026-10-31",
  "needs_review": true
}

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

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

הדרך הרביעית, שבדרך כלל שווה לבדוק קודם: שילוב#

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

כך יכול להיראות מסלול עבודה:

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

מהי למידה, מבחינה חישובית?#

אנחנו אומרים שילד „למד” לזהות כלב אחרי שראה כלבים שונים. אבל מה פירוש הביטוי עבור מערכת ממוחשבת?

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

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

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

למה לא מספיק לבדוק הצלחה על הדוגמאות שלימדו את המודל?#

נניח שאימנו מודל על 1,000 מסמכים, ו־990 מהם זוהו נכון. זה נשמע כמו דיוק של 99%. אבל אם בודקים את אותן דוגמאות שהמודל למד, ייתכן שאנו מודדים במידה רבה שינון, ולא יכולת לזהות חשבונית חדשה מספק אחר. לכן שומרים קבוצת בדיקה שלא שימשה לאימון, ובמערכת אמיתית גם בודקים מדגם מהנתונים שזורמים לאורך זמן.

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

ולא כל מה שנקרא „למידה” משנה את המודל#

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

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

האם אפשר למדוד אם המודל טוב — בלי להתפעל מההדגמה?#

נחזור למסווג החשבוניות. נניח תרחיש לימודי מומצא שבו בדקנו 100 הודעות: 40 באמת מכילות חשבונית, ו־60 אינן חשבוניות. המודל סימן 44 הודעות כחשבוניות. מתוכן, 38 היו נכונות ו־6 טעויות. שתי חשבוניות אמיתיות הוחמצו.

שלושה מדדים עוזרים להבין מה קרה:

דיוק תחזיות חיוביות — Precision: מתוך 44 ההודעות שהמודל סימן כחשבוניות, 38 באמת היו חשבוניות. לכן 38 חלקי 44 הם כ־86.4%. המדד הזה חשוב כשאזעקות שווא יוצרות עבודה מיותרת או גורמות לפעולה בעייתית.

שיעור איתור — Recall: מתוך 40 החשבוניות האמיתיות, המודל מצא 38. לכן 38 חלקי 40 הם 95%. המדד הזה חשוב כשהחמצת חשבונית גורמת לאובדן תיעוד, איחור בתשלום או כשל חשבונאי.

Accuracy — שיעור כל התחזיות הנכונות: 38 ועוד 54, מתוך 100 — כלומר 92%. זה מדד שימושי במקרים מסוימים, אך הוא עלול להטעות כשהקטגוריות אינן מאוזנות או כשהמחיר של שני סוגי השגיאות שונה.

עכשיו מגיעה שאלה של תכנון מערכת, לא של „חוכמת מודל”: האם 95% איתור מספיק? אם אחת מכל 20 חשבוניות הולכת לאיבוד, כנראה שלא. ייתכן שכדאי להוריד את סף ההחלטה ולשלוח יותר הודעות לבדיקה אנושית, במחיר יותר אזעקות שווא.

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

איפה נכנסת הבינה המלאכותית הגנרטיבית?#

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

בעידן הנוכחי מודלי שפה גדולים — LLMs, Large Language Models — אומנו על כמויות גדולות של רצפים טקסטואליים ואחרים, ולמדו דפוסים עשירים של שפה, קוד, ידע ויחסים בין מושגים. מודלים רבים מבוססים על משפחת ארכיטקטורות Transformer, שהוצגה במחקר משנת 2017 [3]. המבנה הטכני של טוקנים, ייצוגים מספריים ומנגנון Attention יקבל פרק עצמאי; אין טעם לדלג מעליו במסווה של „המודל פשוט משלים מילים”.

שלוש התפתחויות מוחשיות מהשנים האחרונות#

2024 — GPT‑4o: OpenAI הציגה מודל שתוכנן לעבד שילובים של טקסט, קול ותמונה ברשת אחת. ההדגמה עזרה להמחיש למה „מודל שפה” כבר אינו תיאור מלא של כל המודלים במשפחה הזאת: הקלט והפלט יכולים לכלול יותר מטקסט [4].

2025 — Claude 3.7 Sonnet: Anthropic הציגה יכולת לעבור בין מענה מהיר לבין השקעת חישוב נוספת בפתרון בעיות מורכבות. זה מדגים שמהירות ותהליך העיבוד בזמן ההפעלה אינם תמיד דבר קבוע; גם אופן הקצאת המשאבים להשגת תשובה הופך לבחירת תכנון [5].

2025 — Gemini 2.5: Google תיארה סדרת מודלים עם יכולות חשיבה מורכבות, קונטקסט ארוך ועיבוד קלט ממספר סוגים. זו דוגמה לאופן שבו בחירת מודל תלויה לא רק באיכות ניסוח, אלא גם בעומס המידע ובמשימה המסוימת [6].

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

למה ייצור טקסט לא מבטיח אמת?#

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

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

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

ניסוי ראשון: להפריד בין כלל, פרשנות ופעולה#

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

שלב א' — יוצרים כלל קשיח. העתקו את הטקסט הבא:

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

סווג את הכותרות:
1. חשבונית מס אוקטובר
2. Invoice for October
3. החשבונית שלכם מחכה — קבלו 40% הנחה
4. תשלום לספק — מסמך מצורף

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

שלב ב' — משנים את ההוראה, לא את הכותרות. עכשיו בקשו:

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

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

שלב ג' — מתכננים פעולה בטוחה. שאלו את המודל:

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

איך מנתחים את התוצאות?#

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

תרגול הבנה: מי עושה מה?#

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

מקרה 1: בכל יום בשעה 08:00 יש להוריד דוח CSV ממערכת ולהכניס אותו לתיקייה. אין צורך להבין את תוכנו. פתרון: אוטומציה עם API או תזמון, בלי צורך מובנה ב־AI.

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

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

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

מה אנחנו יודעים עכשיו — ומה עדיין לא?#

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

אבל כבר אפשר לבצע אבחנה חשובה על כל מוצר שמציגים לנו כ־AI:

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

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

לקראת החלק הבא#

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

מקורות והמשך קריאה#

מקור 1: OECD — Recommendation of the Council on Artificial Intelligence. ההגדרה המעודכנת של מערכת AI. למסמך הרשמי.

מקור 2: OECD (2024) — Explanatory memorandum on the updated OECD definition of an AI system. ההבחנה בין AI סימבולי ללמידת מכונה, ובין אימון להפעלה. למחקר ההסבר.

מקור 3: Vaswani et al. (2017) — Attention Is All You Need. המאמר שהציג את ארכיטקטורת ה־Transformer. למאמר המקורי.

מקור 4: OpenAI (13.5.2024) — Hello GPT‑4o. דוגמה להתפתחות עיבוד מולטימודלי. להודעת ההשקה.

מקור 5: Anthropic (24.2.2025) — Claude 3.7 Sonnet and Claude Code. דוגמה לעיבוד נוסף בזמן הפעלה. להודעת ההשקה.

מקור 6: Google (25.3.2025) — Gemini 2.5: Our newest Gemini model with thinking. דוגמה ליכולות חשיבה וקונטקסט ארוך. להודעת ההשקה.