דלג לתוכן הראשי
קורס מלא — גישה חינמית

AI Automation
Pro

הקורס המקיף ביותר בעברית לאוטומציה עסקית עם AI. תלמד לבנות מערכות אוטומציה מתקדמות עם Make.com ו-n8n, לחבר כלי AI דרך API, ולפרוס 10 פרויקטים עסקיים אמיתיים לפרודקשן.

20 שעות תוכן
10 פרויקטים
גישה מלאה לצמיתות
5 מודולים
ההתקדמות שלך
מודול 1 מתוך 5
1 מודול הושלם מתוך 5
1
מודול 1 — 4 שעות

Make.com מתקדם

פעיל
1.1

Webhooks ב-Make.com

Quick Win

מה זה Webhook ולמה הוא שימושי?

Webhook הוא כתובת URL ייחודית שמאפשרת למערכות חיצוניות "לדפוק בדלת" ולהעביר לך נתונים בזמן אמת — ללא סקר תדיר. במקום ש-Make.com יבדוק כל שתי דקות האם קרה משהו חדש, המערכת הצד-שלישי שולחת בקשת HTTP מיד כשהאירוע קורה. התוצאה: אוטומציה מהירה בהרבה, עם הרבה פחות מכסות API מבוזבזות.

דוגמאות לשימושים נפוצים: קבלת ליד חדש מטופס Typeform, קבלת תשלום מ-Stripe, קבלת הודעה חדשה מ-Slack, עדכון סטטוס הזמנה מ-WooCommerce, ועוד מאות שירותים שתומכים בשליחת Webhooks.

יצירת Webhook ב-Make.com — שלב אחרי שלב

1
הוסף Trigger — Custom Webhook

פתח Scenario חדש ב-Make.com. בחר ב-Trigger הראשון ב-Add a module, חפש "Webhooks" ובחר Custom Webhook. לחץ Add ותן לו שם תיאורי כמו new-lead-webhook.

2
הגדר Instant Trigger

Make.com מייצר לך URL ייחודי. וודא שהאפשרות Instant Trigger מסומנת — זה מה שגורם ל-Scenario לפעול מיידית עם כל בקשה, ולא לחכות לפולינג.

3
שלח בקשת POST לדוגמה

לחץ Determine data structure כדי שMake.com ילמד את מבנה הנתונים שלך. שלח אליו בקשה לדוגמה (ראה קוד למטה) — המערכת תנתח אוטומטית את ה-JSON ותייצר Schema.

4
עיבוד הנתונים

לאחר שהמבנה נלמד, כל השדות שלך (name, email, phone וכד') יהיו זמינים למיפוי במודולים הבאים בScenario. גרור אותם לשדות הרלוונטיים.

קוד: שליחת נתונים ל-Webhook ב-Make.com

אם אתה רוצה לבדוק את ה-Webhook שלך מקוד JavaScript (Node.js, דפדפן, או כל סביבה אחרת), הנה דוגמה מלאה:

send-to-webhook.js
// שליחת נתונים ל-Webhook ב-Make.com
const webhookUrl = 'https://hook.eu1.make.com/YOUR_WEBHOOK_ID';

const data = {
  name: 'ישראל ישראלי',
  email: 'israel@example.com',
  phone: '050-1234567',
  source: 'landing_page',
  timestamp: new Date().toISOString()
};

const response = await fetch(webhookUrl, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(data)
});

console.log('Status:', response.status); // 200 = הצלחה
const text = await response.text();
console.log('Response:', text); // "Accepted" = Make.com קיבל בהצלחה
טיפ: תגובת Make.com

Make.com מחזיר 200 Accepted ברגע שהוא קיבל את הבקשה — גם לפני שה-Scenario הסתיים. אם אתה צריך תגובה אסינכרונית עם תוצאות, השתמש במודול Webhook Response בסוף ה-Scenario.

טעויות נפוצות ואיך להימנע מהן

Content-Type חסר

שכחת להוסיף את ה-header Content-Type: application/json. Make.com לא יפענח את ה-Body ויגיש שגיאת parsing.

Scenario לא פעיל

הWebhook יחזיר 200 גם כאשר ה-Scenario כבוי, אבל הבקשות יצטברו ב-Queue. וודא שה-Scenario פעיל לפני הבדיקה.

שימוש ב-GET במקום POST

Custom Webhook ב-Make.com מצפה לבקשת POST עם Body. שימוש ב-GET ייכשל בקריאת שדות הטופס.

בדיקה עם RequestBin

לפני חיבור Make.com, בדוק את ה-Webhook שלך עם requestbin.com כדי לראות בדיוק מה שולח אליך.

1.2

Advanced Routers ו-Filters

Deep Dive

Router Module — ניתוב לפי תנאים

ה-Router הוא אחד הכלים החזקים ביותר ב-Make.com. הוא מאפשר לך לפצל את ה-Scenario לכמה ענפים (Branches) שכל אחד מהם יפעל בתנאים שונים. תחשוב עליו כמו switch-case בקוד — כל Branch מקבל Filter עם תנאי הפעלה.

דוגמה: ליד שמגיע מפייסבוק נשלח לשיח WhatsApp מיידי, ליד מהאתר מקבל מייל מפורט, ליד מלינקדאין מוזן ישירות ל-CRM. כל Branch רץ עצמאית ובמקביל.

הגדרת Filter Conditions

אופרטורי טקסט
  • Equal to
  • Contains
  • Starts with
  • Matches pattern (RegEx)
אופרטורי מספר
  • Greater than
  • Less than or equal
  • Between
תאריך ומצב
  • Date is before/after
  • Exists / Is empty
  • Is true / Is false

Fallback Route — "אחרת"

כל Router צריך לפחות Branch אחד עם Fallback (Otherwise). זהו ה-Branch שמפעיל את כל הנתונים שלא עברו אף Filter אחר. בלי Fallback, נתונים שלא מתאימים לשום Branch ילכו לאיבוד בשקט — ולא תדע על כך. הדרך הנכונה: הוסף Branch אחרון ב-Otherwise → שלח לעצמך התראה + שמור ב-Error Log.

Nested Routers

ניתן לקנן Routers בתוך Routers ליצירת לוגיקה מורכבת. לדוגמה: Router ראשון מחלק לפי מדינה (ישראל / חו"ל). Branch ישראל עובר ל-Router שני שמחלק לפי עיר. שימוש עיקרי: תהליכי Escalation מורכבים בSales Pipelines.

שים לב: מכסת פעולות

כל Branch ב-Router נחשב לפעולה נפרדת, כולל הפעולות בתוכו. Router עם 5 Branches שכל אחד מכיל 3 מודולים = 15 פעולות לכל הרצה. תכנן את הארכיטקטורה בהתאם למכסה שלך.

1.3

Error Handling ב-Make.com

Deep Dive

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

ארבע הדירקטיבות

B Break

עצור את הריצה וסמן אותה כנכשלת. הנתונים יישמרו ב-Incomplete Executions לטיפול ידני. הדירקטיבה הדיפולטית.

R Resume

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

I Ignore

התעלם מהשגיאה לחלוטין וסמן כהצלחה. בשימוש כאשר השגיאה צפויה ולא חשובה (למשל, Duplicate בDB שמותר).

C Commit

שמור את כל הפעולות שהושלמו עד לנקודת השגיאה. משמש עם Roll Back Transactions למניעת כפילויות.

Error Handler Routes

לחץ לחיצה ימנית על כל מודול ובחר Add error handler. זה מוסיף Branch מיוחד שמופעל רק כשהמודול נכשל. שם תוכל לשים: שליחת מייל לאדמין, הוספת שורה ל-Google Sheets עם פרטי השגיאה, שליחת הודעת Slack, ואז בחירת הדירקטיבה המתאימה.

Retry — ניסיון חוזר אוטומטי

עבור שגיאות רשת זמניות, הגדר Retry בתוך ה-Break directive. הגדר כמות ניסיונות (עד 5) ומרווח בשניות בין כל ניסיון. זה אידיאלי לשיחות API שיכולות להיכשל מ-Rate Limiting.

error-handler-config.json
{
  "errorHandler": "resume",
  "retryCount": 3,
  "retryInterval": 60,
  "fallbackValue": null
}
גישה מומלצת לפרודקשן

הגדר Error Handler על כל מודול קריטי (Google Sheets Write, CRM Update, שליחת מייל). בErr Handler: שמור לשורת Log ← שלח Slack הודעה עם מזהה הריצה ← השתמש ב-Commit ← המשך לרשומה הבאה. כך לעולם לא תאבד נתונים בשקט.

1.4

Data Stores ו-Aggregators

Deep Dive

Data Stores — מסד נתונים מובנה ב-Make.com

Data Store הוא מסד נתונים מינימליסטי שמובנה ישירות בתוך Make.com. הוא מאפשר לך לשמור ולאחזר נתונים בין הרצות שונות של ה-Scenario — משהו שלא ניתן לעשות עם משתנים רגילים. שימושים עיקריים: מניעת עיבוד כפול (Deduplication), שמירת סטטוסים, קאש נתונים, מעקב אחרי ליד לאורך זמן.

כל Data Store מוגדר עם Schema — מבנה השדות שהוא יכיל. לדוגמה: שדה email (Text, Unique), status (Text), last_seen (Date).

Add / Update Record

הוסף רשומה חדשה או עדכן קיימת לפי Key ייחודי

Get Record / Search

אחזר רשומה לפי Key או חפש לפי פילטרים

Delete Record

מחק רשומה ספציפית או נקה את כל ה-Store

Aggregators — איסוף פריטים מ-Iterator

כאשר Iterator מייצר מספר פריטים (לדוגמה: 50 שורות מ-Google Sheets), Aggregator אוסף אותם חזרה לפריט אחד. שלושת ה-Aggregators הנפוצים:

Array Aggregator

אוסף את כל הפריטים לתוך Array אחד. שימושי לשליחת רשימת לידים כ-JSON Body לשירות חיצוני, או בניית Payload מרוכז.

Text Aggregator

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

Numeric Aggregator

מחשב Sum, Average, Min, Max, Count על פני כל הפריטים. שימושי לדוחות יומיים, חישוב הכנסות, ספירת לידים לפי קמפיין.

🎯
פרויקט מודול 1

CRM אוטומטי — מלא ועד לינה

בפרויקט הזה תבנה Scenario שלם ב-Make.com שמקבל ליד חדש מהאתר, מסנן אותו לפי מקור, שומר, שולח הודעות לצוות ומייצר Contact חדש ב-CRM — הכל אוטומטי תוך שניות.

ארכיטקטורת ה-Scenario

1
Trigger — Custom Webhook

מקבל ליד חדש מהאתר. שדות: name, email, phone, source (facebook/website/linkedin), budget

2
Data Store — בדיקת כפילות

חיפוש לפי email ב-Data Store. אם קיים — עדכן תאריך אחרון ועצור. אם לא — המשך ל-Step 3.

3
Router — מיון לפי מקור

Branch A: source = "facebook" ← שלח WhatsApp מיידי. Branch B: source = "linkedin" ← CRM ישיר. Branch C: Otherwise ← מייל ברוכים הבאים.

4
Google Sheets — שמירת הליד

הוסף שורה חדשה בגיליון "לידים". כלול: שם, מייל, טלפון, מקור, תאריך, תקציב, סטטוס (NEW).

5
Gmail — מייל ברוכים הבאים

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

6
Slack — התראה לצוות מכירות

שלח הודעה לערוץ #new-leads: שם הליד, מקור, תקציב, לינק לשורה בSheets. כלול @mention לנציג הרלוונטי.

7
HubSpot / Pipedrive — יצירת Contact

צור Contact חדש ב-CRM עם כל פרטי הליד. הוסף Deal/Opportunity עם שלב "New Lead" וקשר ל-Pipeline המתאים.

אתגר בונוס

הוסף מודול OpenAI לפני שלב Google Sheets. תן לו להעריך את רמת הרצינות של הליד לפי שדה "message" שהוא השאיר בטופס — ובקש ממנו ציון 1-10 + סיבה קצרה. שמור את הציון בגיליון ובCRM כ-Custom Property.

2
מודול 2 — 4 שעות

n8n Self-Hosted

2.1

התקנת n8n על Docker

Quick Win

n8n הוא כלי האוטומציה הקוד-פתוח החזק ביותר שקיים. בניגוד ל-Make.com, כאשר אתה מפעיל n8n Self-Hosted — אין מכסות, אין עלות לפעולה, והנתונים שלך נשארים אצלך. הדרך המהירה להתקין n8n בסביבת פרודקשן היא Docker Compose.

דרישות מוקדמות

Docker + Docker Compose VPS / שרת עם Linux שם דומיין (לSSL) 2GB RAM מינימום

הגדרת docker-compose.yml

docker-compose.yml
# יצירת תיקייה
mkdir n8n-data && cd n8n-data

# docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: '3.1'
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=your-secure-password
      - WEBHOOK_URL=https://your-domain.com/
      - N8N_HOST=your-domain.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
    volumes:
      - ~/.n8n:/home/node/.n8n
EOF

docker compose up -d

הסבר המשתנים

N8N_BASIC_AUTH_ACTIVE

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

N8N_BASIC_AUTH_PASSWORD

בחר סיסמה חזקה. לאחר עלייה לאוויר שנה ל-Variable סביבתי.

WEBHOOK_URL

הכתובת הציבורית שלך. n8n ישתמש בה לבניית כתובות Webhook. חייב להיות HTTPS.

volumes: ~/.n8n

שמור את הנתונים מחוץ ל-Container. בלי זה תאבד את כל ה-Workflows בכל Restart.

HTTPS עם Nginx + Certbot

לפרודקשן עם דומיין אמיתי, הוסף Nginx כ-Reverse Proxy עם SSL מ-Let's Encrypt. הפקודה: certbot --nginx -d your-domain.com. הקורס כולל Nginx config מלא עם Rate Limiting.

2.2

Workflows מורכבים ו-Code Nodes

Deep Dive

n8n מציע Code Node שמאפשר לך לכתוב JavaScript (או Python) ישירות בתוך ה-Workflow. זה הופך כל פעולה שניתן לקוד — לאפשרית. ניקוי נתונים, חישובים מורכבים, בניית Payloads דינמיים, ועיבוד לוגיקה עסקית שלא קיימת כ-Node מובנה.

n8n Code Node — עיבוד ליד
// n8n Code Node — עיבוד ליד מ-CRM
const items = $input.all();
const processed = items.map(item => {
  const data = item.json;

  // נקה מספר טלפון ישראלי
  const phone = data.phone?.replace(/\D/g, '');
  const formattedPhone = phone?.startsWith('972')
    ? `+${phone}`
    : `+972${phone?.replace(/^0/, '')}`;

  // חשב Lead Score
  let score = 0;
  if (data.email?.endsWith('.co.il')) score += 20;
  if (data.company) score += 30;
  if (data.budget > 10000) score += 50;

  return {
    json: {
      ...data,
      phone: formattedPhone,
      leadScore: score,
      processedAt: new Date().toISOString()
    }
  };
});

return processed;

הקוד מקבל את כל הפריטים ($input.all()), עובר על כולם ב-map, מנרמל את הטלפון, מחשב Lead Score בהתאם לקריטריונים עסקיים, ומחזיר את הנתונים המועשרים לNodeים הבאים. שים לב שיש לחזיר תמיד מערך של אובייקטים עם שדה json.

2.3

AI Nodes ב-n8n

Deep Dive

n8n 1.x כולל תמיכה מלאה ב-LangChain ישירות בממשק. ניתן לבנות AI Agents, שרשראות Prompts, ושיחות עם Memory — הכל בלי שורת קוד.

AI Agent Node

Node שמריץ Agent מלא עם Tools. הגדר את ה-System Prompt, חבר Tools (Webhooks, APIs, SQL), והוא יחליט אוטומטית מה להשתמש.

Memory Nodes

Window Buffer Memory שומר את ה-N הודעות האחרונות. Redis Chat Memory לזיכרון ארוך-טווח. Postgres/SQLite לשמירה קבועה.

OpenAI Chat Model

חיבור ישיר ל-GPT-4o, GPT-4 Turbo ו-GPT-3.5. כולל הגדרות Temperature, Max Tokens, ו-System Message.

LangChain Integration

כל Node של LangChain זמין: Document Loaders, Text Splitters, Vector Store Retrievers, Embeddings, ועוד.

2.4

Security ב-n8n Self-Hosted

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

Basic Auth / OAuth2

הגן על ממשק n8n עם Basic Auth. לסביבות מרובות משתמשים — הפעל n8n User Management ועבור ל-OAuth2 עם גוגל.

Credentials Encryption

הגדר N8N_ENCRYPTION_KEY — מחרוזת ארוכה ואקראית. n8n ישתמש בו להצפין את כל ה-Credentials. גבה מפתח זה בנפרד!

Firewall + IP Whitelist

אם ה-n8n אינו נחוץ לגישה ציבורית, הגבל גישה ל-Port 5678 לIP הספציפי שלך בלבד. השאר את Port 443 פתוח לWebhooks בלבד.

גיבוי אוטומטי

הגדר Cron Job יומי שדוחף את ~/.n8n ל-S3 או Google Drive. גיבוי בלי תוכנית שחזור אינו גיבוי.

🎯
פרויקט מודול 2

Lead Management Pipeline עם AI Scoring

בפרויקט זה תבנה Workflow ב-n8n שמטפל בלידים נכנסים, מעביר אותם דרך Code Node לעיבוד ורק לאחר מכן מדרג אותם עם GPT-4o — ואז מנתב אוטומטית לנציג הנכון.

1
Webhook Trigger

קבלת ליד מ-Typeform/HubSpot Forms עם כל שדות הטופס

2
Code Node — נרמול נתונים

ניקוי טלפון, ניתוח דומיין email לזיהוי חברה, חישוב Lead Score ראשוני

3
OpenAI Node — AI Score

שלח את תוכן הפנייה ל-GPT-4o: "דרג את הליד הזה 1-10 לפי רמת הרצינות" + JSON מובנה בתגובה

4
IF Node — ניתוב לפי ציון

ציון ≥ 8: נציג בכיר + WhatsApp מיידי. ציון 5-7: תהליך מייל רגיל. ציון < 5: ניוזלטר בלבד

5
Postgres / Airtable

שמור את כל הנתונים כולל AI Score, ציון ידני שיוגדר אחר כך, היסטוריית פניות

מודולים 3–5

לחץ על כל מודול לניווט לתוכן המלא שלו

4
מודול 4 — 5 שעות

10 Business Automation Projects

עשרה פרויקטים עסקיים מלאים מוכנים לפרודקשן. כל פרויקט כולל תיעוד, קוד להורדה, וסרטון Walk-through. הפרויקטים עוסקים בתחומים: E-commerce, שירות לקוחות, HR, מכירות, שיווק ותוכן.

P1
Order-to-Delivery Tracker

WooCommerce + Shipping API + WhatsApp עדכונים

P2
Customer Support Triage

סיווג פניות לקוח עם GPT-4 + העברה לנציג

P3
Social Media Content Engine

יצירת תוכן שבועי עם AI + תזמון פרסום

P4
CV Screening Pipeline

קריאת קורות חיים + ניקוד + דוח למנהל

P5
Invoice Processing Bot

מיצוי נתונים מחשבוניות PDF + רישום ב-ERP

P6
Competitor Intelligence

Scraping + AI Summary + דוח שבועי אוטומטי

P7
Meeting Notes Automation

תמלול Zoom/Meet + סיכום + משימות ב-Asana

P8
Inventory Alert System

בדיקת מלאי + הזמנה אוטומטית + דוח לאחראי

P9
Personalized Email Sequences

סדרת מיילים מותאמת-אישית עם GPT-4 + A/B Testing

P10
Full Sales Dashboard

אוסף נתוני CRM + חישובים + Google Data Studio

5
מודול 5 — 2 שעות

Production, Monitoring & Scale

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

אישור סיום קורס

לאחר השלמת כל 5 המודולים ו-10 הפרויקטים תקבל אישור דיגיטלי מ-Automation4MI. ניתן לשיתוף ב-LinkedIn.

3
מודול 3 — 5 שעות

AI API Integration

3.1

OpenAI API מ-0

יסודות

עד עכשיו עבדת עם AI דרך צמתים מוכנים ב-Make וב-n8n. הצומת עושה עבורך שלושה דברים: מחזיק את המפתח, בונה את הבקשה, ומפרש את התשובה. ברגע שאתה קורא ל-API ישירות, שלושת הדברים האלה עוברים אליך — וזה בדיוק מה שנותן לך שליטה על עלות, על פורמט ועל טיפול בשגיאות.

מפתח API — ואיפה הוא לא אמור להיות

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

setup.sh
pip install openai python-dotenv

# .env  — לא נכנס ל-git לעולם
echo 'OPENAI_API_KEY=sk-proj-...' > .env
echo '.env' >> .gitignore
first_call.py
import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

resp = client.chat.completions.create(
    model="gpt-5-mini",
    messages=[
        {"role": "system", "content": "אתה עוזר תמציתי. ענה בעברית."},
        {"role": "user",   "content": "סכם בשתי שורות מה עושה webhook."},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage)   # prompt_tokens, completion_tokens, total_tokens

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

איזה מודל לבחור

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

מודל קטן

סיווג, חילוץ נתונים, תיוג, ניסוח קצר, תרגום. זה 80% מהקריאות באוטומציה טיפוסית.

מודל גדול

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

להעריך עלות לפני שמריצים אלף פעם

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

estimate.py
PRICE_IN  = 0.25 / 1_000_000    # $ לטוקן קלט - עדכן מהמחירון
PRICE_OUT = 2.00 / 1_000_000    # $ לטוקן פלט

u = resp.usage
per_call = u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT

for runs in (100, 1_000, 10_000):
    print(f"{runs:>6} ריצות: ${per_call * runs:.2f}")
הקבע לפני המשתנה

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

תרגיל

קח פרומפט אמיתי מאוטומציה שבנית במודול 1 או 2, הרץ אותו פעם אחת דרך ה-API, והדפס את usage. חשב מה זה עולה ב-1,000 ריצות בחודש. אם המספר מפתיע אותך — נסה מודל קטן יותר על אותו קלט והשווה גם עלות וגם איכות.

3.2

Structured Outputs ו-Function Calling

קריטי

זה השיעור שמפריד בין הדגמה לאוטומציה שרצה בלילה. מודל שמחזיר טקסט חופשי הוא בעיה: היום הוא יענה {"status":"חם"}, מחר יוסיף "בטח! הנה ה-JSON:" לפני, ומחרתיים יכתוב "hot" באנגלית. הצומת הבא בזרימה נשבר, ואף אחד לא ידע עד שמישהו יבדוק.

הפתרון אינו לבקש יפה יותר. הוא לכפות סכמה, ברמת ה-API.

structured.py
from pydantic import BaseModel, Field
from typing import Literal

class Lead(BaseModel):
    company:   str
    contact:   str
    intent:    Literal["חם", "פושר", "קר"]
    budget_ils: int | None = Field(None, description="תקציב אם צוין, אחרת null")
    next_step: str

resp = client.chat.completions.parse(
    model="gpt-5-mini",
    messages=[
        {"role": "system", "content": "חלץ פרטי ליד מהפנייה. אל תמציא שדה שלא מופיע."},
        {"role": "user",   "content": email_body},
    ],
    response_format=Lead,          # הסכמה נכפית בצד השרת
)

lead = resp.choices[0].message.parsed   # אובייקט Lead, לא מחרוזת
print(lead.intent, lead.budget_ils)

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

Function Calling — כשהמודל צריך לפעול

Structured Outputs מחזיר לך נתונים. Function Calling נותן למודל להחליט איזו פעולה לבצע ובאילו פרמטרים. ההבדל חשוב: בראשון אתה יודע מראש מה יחזור, בשני אתה נותן למודל בחירה.

tools.py
tools = [{
    "type": "function",
    "function": {
        "name": "create_deal",
        "description": "פותח עסקה חדשה ב-CRM. השתמש רק כשיש שם חברה ואיש קשר.",
        "parameters": {
            "type": "object",
            "properties": {
                "company": {"type": "string"},
                "amount":  {"type": "number", "description": "בשקלים"},
                "stage":   {"type": "string", "enum": ["ליד", "הצעה", "מו״מ"]},
            },
            "required": ["company", "stage"],
            "additionalProperties": False,
        },
    },
}]

resp = client.chat.completions.create(
    model="gpt-5-mini", messages=messages, tools=tools,
)

call = resp.choices[0].message.tool_calls
if call:
    args = json.loads(call[0].function.arguments)
    create_deal(**args)          # הקוד שלך מבצע. המודל רק החליט.
ה-description הוא הפרומפט

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

Retry — ומה לא לנסות שוב

שגיאות API נחלקות לשתיים, והטיפול בהן הפוך. 429 ו-5xx הן זמניות — נסה שוב עם השהיה גדלה. 400 ו-401 הן שגיאות שלך — ניסיון חוזר רק יבזבז קריאות ויחייב אותך.

retry.py
import time, random
from openai import RateLimitError, APIStatusError

def call_with_retry(fn, attempts=4):
    for i in range(attempts):
        try:
            return fn()
        except RateLimitError:
            pass                                  # זמני - שווה לנסות
        except APIStatusError as e:
            if e.status_code < 500:
                raise                             # שלנו - אל תנסה שוב
        wait = 2 ** i + random.random()           # jitter נגד עדר
        print(f"ניסיון {i+1} נכשל, ממתין {wait:.1f}ש")
        time.sleep(wait)
    raise RuntimeError("נכשל אחרי כל הניסיונות")

ה-random() בשורת ההמתנה אינו קישוט. בלעדיו, מאה קריאות שנכשלו יחד ינסו שוב יחד בדיוק, וייכשלו יחד שוב.

3.3

Vision API — עיבוד תמונות

Quick Win

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

שתי דרכים לשלוח תמונה

URL אם התמונה כבר ברשת ונגישה בלי אימות. Base64 אם היא אצלך — קובץ מקומי, קובץ מ-Drive, או תמונה שהגיעה מ-webhook. השנייה נפוצה יותר באוטומציה.

invoice_ocr.py
import base64
from pydantic import BaseModel

def to_data_url(path: str) -> str:
    mime = "image/png" if path.endswith(".png") else "image/jpeg"
    with open(path, "rb") as f:
        return f"data:{mime};base64," + base64.b64encode(f.read()).decode()

class Invoice(BaseModel):
    supplier:    str
    invoice_no:  str
    date:        str          # YYYY-MM-DD
    total_ils:   float
    vat_ils:     float | None
    line_items:  list[str]

resp = client.chat.completions.parse(
    model="gpt-5-mini",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text":
             "חלץ את פרטי החשבונית. אם שדה לא מופיע בבירור - החזר null. "
             "אל תשלים מספרים מהערכה."},
            {"type": "image_url",
             "image_url": {"url": to_data_url("invoice.jpg"), "detail": "high"}},
        ],
    }],
    response_format=Invoice,
)

inv = resp.choices[0].message.parsed
חשבוניות בעברית

זה החלק שמדריכים באנגלית לא מכסים. שלושה דברים שנשברים: מספרים בעברית נקראים סביר, אבל מספר חשבונית שמעורב בטקסט עברי מתהפך לפעמים בסדר הספרות — הצלב מול הסכום. תאריכים בפורמט ישראלי (04/09/26) עמומים — בקש במפורש YYYY-MM-DD והוסף "התאריך בפורמט יום/חודש/שנה". ומע״מ מופיע לעתים כשורה נפרדת ולעתים מוטמע בסכום — בקש את שניהם והשווה.

detail — הפרמטר שמשנה עלות פי כמה

low

מספר טוקנים קבוע וקטן. מספיק ל"מה יש בתמונה", לסיווג, ולזיהוי סוג מסמך. זול משמעותית.

high

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

זרימה שחוסכת: הרץ קודם low כדי לסווג מה זה, ורק אם זו חשבונית — הרץ high לחילוץ. בתיבת מייל שמקבלת גם ספאם, זה חוסך את רוב הקריאות היקרות.

אזהרה שחייבים לומר

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

3.4

Embeddings ו-Vector Search

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

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

embed.py
def embed(texts: list[str]) -> list[list[float]]:
    # שלח באצווה - קריאה אחת ל-100 קטעים, לא 100 קריאות
    r = client.embeddings.create(
        model="text-embedding-3-small",
        input=texts,
    )
    return [d.embedding for d in r.data]

vecs = embed(["מדיניות החזרות", "שעות פעילות", "אחריות על מוצר"])
print(len(vecs[0]))     # ממדי הווקטור

Pinecone — אחסון וחיפוש

pinecone_store.py
from pinecone import Pinecone

pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"])
index = pc.Index("company-docs")

# כתיבה - שמור את הטקסט ב-metadata, אחרת יש לך מספרים בלי מקור
index.upsert([
    {"id": f"doc-{i}",
     "values": v,
     "metadata": {"text": t, "source": "policy.pdf", "page": i}}
    for i, (t, v) in enumerate(zip(chunks, embed(chunks)))
])

# חיפוש
q = embed(["איך מבטלים הזמנה?"])[0]
hits = index.query(vector=q, top_k=5, include_metadata=True)

for h in hits.matches:
    print(round(h.score, 3), h.metadata["source"], h.metadata["text"][:60])
שתי מלכודות שיעלו לך יום

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

מה לגבי עברית

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

3.5

RAG Pipeline מלא

שיא המודול

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

Chunking — כאן נופלות רוב המערכות

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

chunk.py
def chunk(text: str, size=900, overlap=150) -> list[str]:
    """חותך על גבול פסקה, לא באמצע משפט."""
    paras = [p.strip() for p in text.split("\n\n") if p.strip()]
    out, cur = [], ""
    for p in paras:
        if len(cur) + len(p) < size:
            cur += ("\n\n" if cur else "") + p
        else:
            if cur:
                out.append(cur)
            # חפיפה: סוף הקטע הקודם נכנס לתחילת הבא
            cur = (cur[-overlap:] + "\n\n" + p) if cur else p
    if cur:
        out.append(cur)
    return out

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

הצינור המלא

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

def ask(question: str, top_k: int = 5) -> str:
    q_vec = embed([question])[0]
    hits  = index.query(vector=q_vec, top_k=top_k, include_metadata=True)

    # סף רלוונטיות - עדיף לא לענות מלענות על סמך זבל
    good = [h for h in hits.matches if h.score > 0.35]
    if not good:
        return "אין לי מידע על כך במסמכים."

    context = "\n\n---\n\n".join(
        f"[{h.metadata['source']}]\n{h.metadata['text']}" for h in good
    )

    r = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[
            {"role": "system", "content": SYSTEM},
            {"role": "user", "content": f"מקורות:\n{context}\n\nשאלה: {question}"},
        ],
    )
    return r.choices[0].message.content

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

כשהתשובות גרועות — אבחן לפי הסדר

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

מה שלא כיסינו וכדאי שתדע

RAG בסיסי מספיק לרוב המקרים. כשהוא לא מספיק, שני השדרוגים הבאים הם reranking — שליפת 20 קטעים ודירוגם מחדש במודל ייעודי לפני שנשלחים חמישה — וhybrid search, שילוב חיפוש סמנטי עם חיפוש מילולי כדי לתפוס מספרי דגם ומונחים מדויקים שהסמנטי מפספס.

🎯
פרויקט מודול 3

צ'אטבוט עם ידע מותאם

תבנה צ'אטבוט שעונה על שאלות לקוחות מתוך מסמכי החברה בלבד — ומודה כשאין לו תשובה. הוא ייחשף דרך webhook ב-Make.com, כך שאפשר לחבר אליו טופס באתר, ווטסאפ או צ'אט פנימי.

מה תבנה

1. אינדוקס (רץ פעם, ובכל עדכון מסמך)

קריאת קבצי המדיניות, חלוקה לקטעים, embedding, כתיבה ל-Pinecone עם מקור ומספר עמוד ב-metadata.

2. שאילתה (רץ בכל שאלה)

webhook מקבל שאלה, שולף קטעים מעל הסף, מייצר תשובה עם ציון מקורות, מחזיר JSON.

3. שער אנושי

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

4. חיבור ב-Make

Webhook → HTTP לשירות שלך → Router: יש תשובה או אין → תגובה ללקוח או התראה לצוות.

app.py — נקודת הקצה
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Q(BaseModel):
    question: str
    user_id: str | None = None

@app.post("/ask")
def ask_endpoint(q: Q):
    answer = ask(q.question)
    unanswered = answer.startswith("אין לי מידע")

    if unanswered:
        log_gap(q.question, q.user_id)   # לגיליון - הפער שצריך לכסות

    return {"answer": answer, "answered": not unanswered}

קריטריוני קבלה

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

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

5
מודול 5 — 2 שעות

Production, Monitoring & Scale

5.1

Production Deployment Checklist

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

סודות — לא בזרימה

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

n8n

Credentials מוצפנים ב-N8N_ENCRYPTION_KEY. גבה את המפתח הזה בנפרד — בלעדיו הגיבוי חסר ערך.

Make.com

Connections ברמת החשבון. אל תשים מפתח בשדה טקסט של מודול HTTP.

קוד משלך

משתני סביבה בלבד. .env ב-.gitignore, וסודות פרודקשן ב-Secrets של פלטפורמת הפריסה.

רוטציה

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

Staging — למה זה לא מותרות

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

config.py
import os

ENV = os.getenv("APP_ENV", "staging")   # ברירת מחדל בטוחה

TARGETS = {
    "staging":    {"sheet": "leads-test",  "slack": "#bot-test",
                   "notify": "me@example.com"},
    "production": {"sheet": "leads",       "slack": "#sales",
                   "notify": "sales@example.com"},
}[ENV]

if ENV == "production" and not os.getenv("I_MEAN_IT"):
    raise SystemExit("פרודקשן דורש אישור מפורש")

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

רשימת בדיקה לפני העלאה

כל סוד יושב ב-Credentials או במשתנה סביבה, ואף אחד לא בזרימה עצמה.
הזרימה מיוצאת ושמורה — ב-git אם אפשר. n8n מייצא JSON; זה מאפשר לראות מה השתנה ולחזור אחורה.
נתיב הכישלון נבדק, לא רק נתיב ההצלחה. נתק את ה-API בכוונה וראה מה קורה.
יש התראה על כישלון. בלעדיה אין טעם בכל השאר.
פעולה שכותבת או שולחת עוברת דרך בדיקת כפילות — מפתח ייחודי, בדיקה לפני כתיבה.
CI/CD — הגרסה המינימלית

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

5.2

Monitoring & Alerting

החשוב ביותר

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

מקרה אמיתי מהמערכת של האתר הזה

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

שלוש שכבות, לפי סדר החשיבות

1. התראת כישלון

הזרימה נפלה — הודעה מיידית. חמש דקות עבודה, וזה 80% מהערך של כל הניטור.

2. Heartbeat

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

3. מדדים

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

מה לא לעשות

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

Error Workflow ב-n8n

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

Error Trigger → Code node
const e = $input.first().json;

return [{ json: {
  text:
    `🔴 *${e.workflow.name}* נכשלה\n` +
    `צומת: ${e.execution.lastNodeExecuted}\n` +
    `שגיאה: ${e.execution.error?.message ?? 'לא ידוע'}\n` +
    `<${e.execution.url}|פתח את ההרצה>`
}}];

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

Heartbeat — לתפוס את מה שלא צועק

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

בסוף כל זרימה מתוזמנת
# HTTP Request node, בסוף הזרימה, אחרי ההצלחה
GET https://uptime.example.com/api/push/<token>

# Uptime Kuma מוגדר כ-"Push" עם Heartbeat Interval של 65 דקות
# לזרימה שרצה כל שעה. אם לא הגיע דיווח - התראה.
קבע את החלון רחב מהמחזור

זרימה שרצה כל שעה — חלון של 65–70 דקות, לא 60. ריצה שהתעכבה בדקה תייצר התראת שווא, ושתיים כאלה מלמדות את הצוות להתעלם. עדיף להתריע חמש דקות מאוחר יותר מאשר להתריע כשהכול תקין.

מה למדוד — ומה לא

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

מה שלא שווה למדוד: כל השאר. לוח עם עשרים גרפים לא נצפה, ומה שלא נצפה אינו ניטור.

התרגיל האחרון בקורס

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

כל חמשת המודולים פתוחים

מוכן לפרויקט הבא?

המודולים 1 עד 5 זמינים במלואם — מ-Make.com מתקדם, דרך n8n בהרצה עצמית וחיבור ישיר ל-API של מודלי שפה, ועד העלאה לפרודקשן עם ניטור. עשרת הפרויקטים מחכים במודול 4.

לעשרת הפרויקטים
קהילת Discord הפרטית

חיבור לקהילה בלעדית של תלמידי AI Automation Pro. שאל שאלות, שתף פרויקטים, קבל Feedback ממנטורים ומתלמידים בכירים.