GreatMinds_Logo

Great·Minds#9

#hybrid

16-18 Dec 2025
כ"ו-כ"ח כסלו, תשפ"ו

לב | נווה | מבחר


הרשמה לסטודנטים

הרשמה למנטורים

הרשמה לחברות (אתגר)

ההרשמה תיפתח בקרוב

ההרשמה לסטודנטים נסגרה
ההרשמה תיסגר ב-26/05 בשעה 23:30

מתעניינים במתן חסות להאקתון?

סוגי חסויות

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

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

הצצה להאקתון הגברים השלישי:
הצצה להאקתון הגברים השני:

איך זה יעבוד?

General

נרשמים

וממלאים טופס קצר

General

משתבצים

מקימים או מצטרפים לקבוצה ובוחרים אתגר

General

מתכוננים

בסדנאות הכנה כלליות וקבוצתיות

General

פותרים

את האתגרים במהלך ההאקתון בליווי מנטורים



מחפשים להצטרף או לצרף לקבוצה בהאקתון?

לשם כך פתחנו לכם קבוצת ווטסאפ ומאגר למחפשים להצטרף לקבוצה או לצרף לקבוצה

לרישום במאגר משתתפים/קבוצות

מאגר משתתפים/קבוצות



enter
כניסה להאקתון

פרטי וגובה הפרסים יעודכנו בהקדם

פרס ראשון

3000₪

פרס שני

2000₪

פרס שלישי

1500₪

מימוש כספי הזכייה לטובת קידום המיזם יגדיל את הפרס ל:

6000₪

4000₪

3000₪

לו"ז


הלו"ז יתפרסם כאן לקראת ההאקתון

לו"ז


יום שלישי 2/12


מפגש עבודה 1

19:00 התחלת עבודה
בליווי מנטורים
מרכז היזמות
20:00 נשנושים מרכז היזמות
22:00 סיום מרכז היזמות

יום שלישי 9/12


מפגש עבודה 2

19:00 התחלת עבודה
בליווי מנטורים
מרכז היזמות
20:00 נשנושים מרכז היזמות
22:00 סיום מרכז היזמות

יום שלישי 16/12


מתחילים בכל הכוח

11:00 קבלת פנים - בראנצ’ אודיטוריום
12:00 אירוע פתיחה אודיטוריום
12:30 מתחילים לעבוד חדר אוכל
14:00 הגשת דו"ח פרטי קבוצה סילבוס
14:30 מפגש ראשי קבוצות
טיפים לניהול קבוצה בהאקתון
סוכו 210
16:00 תפילת מנחה חדר אוכל
17:00 תפילת ערבית חדר אוכל
17:15 הדלקת נרות + סופגניות חדר אוכל
19:00 ארוחת ערב חדר אוכל
21:00 דגשים לפרזנטציה
(2 נציגים מכל קבוצה, טכני ושיווקי)
סוכו 210
22:00 הגשת דו"ח תמונת מצב 3 סילבוס
22:30 הגרלה לסדר ההצגות בחצי הגמר חדר אוכל
00:00 ארוחת לילה + הגרלת פרסים (לנוכחים בלבד) חדר אוכל

יום רביעי 17/12


קפה שחור חזק

07:00 תפילת שחרית ביהמ"ד
08:00 ארוחת בוקר והמשך פיתוח קבוצתי חדר אוכל
09:00 העלאת מצגת למשוב סילבוס
11:00 תמונת אווירה משותפת חדר אוכל
12:30 ארוחת צהריים חדר אוכל
16:00 תפילת מנחה חדר אוכל
17:00 תפילת ערבית חדר אוכל
17:15 הדלקת נרות + סופגניות חדר אוכל
18:30 חצי הגמר
חזרה גנרלית לפרזנטציות + פידבקים
אודיטוריום
19:00 ארוחת ערב חדר אוכל
19:30 המשך חצי הגמר
חזרה גנרלית לפרזנטציות + פידבקים
אודיטוריום
20:00 סבב הערכת מורכבות טכנולוגית חדר אוכל
00:00 ארוחת לילה + הגרלת פרסים (לנוכחים בלבד) חדר אוכל

יום חמישי 18/12


שיפוט והכרזה על זוכים

03:00 סיום משוער לחצי הגמר -
06:00 מעבר על שיפורים
לצורך החלטה על עלייה לגמר
חדר אוכל
07:00 הכרזה על עולים לגמר לובי
07:30 תפילת שחרית ביהמ"ד
08:00 סוף זמן שליחת מצגות לגמר סילבוס
08:30 ארוחת בוקר חדר אוכל
10:00 אירוע הגמר
הצגת הפרויקטים בפני שופטים
אודיטוריום
12:00 בראנצ' אודיטוריום
12:30 הכרזה על הזוכים אודיטוריום

הלו"ז המלא יופיע בקרוב


סדנאות הכנה


מידע על הסדנאות יתפרסם לקראת ההאקתון

סדנאות הכנה


lecturer

פולסטאק חלק א' - פיתוח

בואו ללמוד את יסודות הפיתוח במערכות Full Stack! בסדנה הזו נכסה את כל מה שצריך כדי להקים צד לקוח ושרת ולהתחיל לפתח מערכות שלימות מאפס. נבנה פרויקט מקצה לקצה ונלמד איך לשלב בין כלים וטכנולוגיות כדי ליצור בסיס חזק להמשך פיתוח.
ינון בלוך, CTO at SpotReality
יום רביעי | 20/11 19:00-22:00

קמפוס לב

lecturer

פולסטאק חלק ב' - דבאופס

הכירו את הדבאופס: איך להשיק מערכות בזמן קצר ואיך להבטיח את תפקודן היציב והבטוח בסביבה דינאמית. נלמד כלים ליישום מהיר בענן ושימוש ב-Docker להרצת מערכות בפרודקשן. הסדנה תתמקד בכל מה שצריך כדי להעלות את המוצר שלכם לאוויר בצורה יעילה ונכונה.
אליה בלוך, CTO at BonData
יום רביעי | 27/11 19:00-22:00

קמפוס לב

lecturer

GPT וחברים

כל יום יוצאים לשוק כלים חדשים בעולמות ה-Generative AI (בינה מלאכותית יוצרת). הכלים האלה משנים את צורת העבודה במקצועות שלמים. בסדנה נסקור כלים שונים בתחום ונראה איך הם יכולים לעזור לכן להגיע להישגים בהאקתון הכי רחוק שאפשר.
אלכס לואיס, Team Leader at C41 Corps
יום ראשון | 28/05 19:30-21:30

זום

lecturer

פיתוח עם AI בלי לכתוב קוד

בניית פרויקט מלא מאפס באמצעות שימוש בבינה מלאכותית בלבד!
מתן פחימה, חוקר ומפתח בינה מלאכותית, nRich
יום רביעי | 26/06 19:30-22:00

קמפוס לב

lecturer

AI מעשי - להפוך רעיונות למוצרים מוגמרים בעזרת כלים חכמים

הכירו את הכלים המתקדמים בעולם הבינה המלאכותית שיכולים להפוך את הרעיון שלכם למוצר חי ונושם. בסדנה נתנסה בעבודה עם כלים פרקטיים ליצירת אב-טיפוס מהיר וממשקים חכמים, נלמד לכתוב פרומפטים בצורה נכונה ונראה איך להשתמש ב-AI לכתיבת קוד, עיצוב, פתרון בעיות, סקר שוק ועוד. זה הבסיס שמאפשר לכם לעבור בקלות מהרעיון לביצוע.
ערן יומטוביאן, Director at Schreiber LevTech Entrepreneurship Center
יום שלישי | 3/12 19:00-21:30

קמפוס לב

lecturer

חומרה חכמה – יצירת פרויקטים עם ESP ורכיבים אלקטרוניים

בואו ללמוד איך לתקשר עם העולם הפיזי דרך קוד! בסדנה הזו נצלול לעולם החומרה ונעבוד עם בקרי ESP, חיישנים וצ'יפים נוספים – נלמד איך לשלוט ולקרוא מידע מרכיבים אלקטרוניים, נבין את עקרונות התקשורת ביניהם, ונבנה פרויקטים שיחבר בין כל אלה. הסדנה תשלב עבודה מעשית, תכנות, והרבה יצירתיות.
ד"ר אבי טרייסטמן, Computer Science Lecturer at Lev Academic Center
יום שלישי | 25/11 19:00-21:30

קמפוס לב

lecturer

איך מנצחים האקתון

עם ניסיון שנאסף מהשתתפות, מנטורינג והפקה בעשרות האקתונים בסדנה הזו תקבלו את כל הטיפים והשיטות שיעזרו לכם לנצח האקתון. הסדנה תתחיל בחצי שעה של שו"ת על ההאקתון!
ערן יומטוביאן, Director at Schreiber LevTech Entrepreneurship Center
יום ראשון | 30/11 19:00-21:30

קמפוס לב

lecturer

איך מנצחים האקתון

עם ניסיון שנאסף מהשתתפות, מנטורינג והפקה בעשרות האקתונים בסדנה הזו תקבלו את כל הטיפים והשיטות שיעזרו לכן לנצח האקתוןניסיון של עשרות האקתונים מרוכז כאן בסדנה אחת! נדבר על הכנה אסטרטגית, ניהול זמנים ושיטות עבודה בצוות – כל מה שדרוש כדי לבלוט ולנצח בתחרות. נתחיל בשו"ת פתוח עם פיצות, ונמשיך עם כל הטיפים להצלחה בהאקתון.
ערן יומטוביאן, Director at Schreiber LevTech Entrepreneurship Center
יום ראשון | 8/12 19:00-21:30

קמפוס לב

שופטים

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

שופטים
Aaron Zucker

Aaron Zucker

Founder & Managing Partner, Sapir Venture Partners

Dotan Levi

Dotan Levi

Architecture Manager, Nvidia

Gabi Levenberg

Gabi Levenberg

Co-Founder, CYE

Lt. Col. (Res.) Avi Avraham

Lt. Col. (Res.) Avi Avraham

CEO, Dor Information Technologies

Noam Fraenkel

Noam Fraenkel

Principal Architect, JFrog

Yaron Magal

Yaron Magal

CEO, The Israel Center for Advanced Photonics (ICAP)


מנטורים

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

איתור מנטורים


מה

היכן

מתי

יוסף גולובצ'וב
JCT
02/12 - 20:30 - 22:00 | זום
09/12 - 20:30 - 22:00 | זום
16/12 - 19:00 - 21:00 | זום
17/12 - 12:00 - 14:00 | זום
17/12 - 14:00 - 16:00 | זום
17/12 - 16:00 - 18:00 | זום
אבי טרייסטמן
JCT
16/12 - 17:00 - 19:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב
16/12 - 23:00 - 01:00 | קמפוס לב
17/12 - 10:00 - 12:00 | קמפוס לב
17/12 - 12:00 - 14:00 | קמפוס לב
17/12 - 14:00 - 16:00 | קמפוס לב
17/12 - 18:00 - 20:00 | קמפוס לב
17/12 - 20:00 - 22:00 | קמפוס לב
17/12 - 22:00 - 00:00 | קמפוס לב
18/12 - 00:00 - 02:00 | קמפוס לב
אבי רוזנפלד
JCT
17/12 - 18:00 - 20:00 | זום
אבירם זילברמן
JCT
09/12 - 20:30 - 22:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב
17/12 - 22:00 - 00:00 | קמפוס לב
18/12 - 00:00 - 02:00 | קמפוס לב
אבישי פרקש
IDF
אביתר כץ
Innoveast
16/12 - 13:00 - 15:00 | זום
16/12 - 15:00 - 17:00 | זום
16/12 - 23:00 - 01:00 | זום
17/12 - 22:00 - 00:00 | זום
אור ממן
Cymulate
16/12 - 21:00 - 23:00 | קמפוס לב
אורי קסלר
PEACH
17/12 - 18:00 - 20:00 | קמפוס לב
אוריאל אופיר
בנק לאומי
09/12 - 19:00 - 20:30 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
17/12 - 18:00 - 20:00 | קמפוס לב
אוריאל ניימן
ברזילי ושות'
17/12 - 20:00 - 22:00 | זום
אלון בלושטיין
עצמאי
17/12 - 10:00 - 12:00 | קמפוס לב
17/12 - 12:00 - 14:00 | קמפוס לב
אלון יומטוביאן
Snapio.ai
02/12 - 19:00 - 20:30 | זום
02/12 - 20:30 - 22:00 | זום
09/12 - 19:00 - 20:30 | זום
09/12 - 20:30 - 22:00 | זום
16/12 - 13:00 - 15:00 | זום
16/12 - 15:00 - 17:00 | זום
16/12 - 17:00 - 19:00 | זום
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב
16/12 - 23:00 - 01:00 | זום
17/12 - 01:00 - 03:00 | זום
17/12 - 10:00 - 12:00 | זום
17/12 - 12:00 - 14:00 | זום
17/12 - 14:00 - 16:00 | זום
17/12 - 16:00 - 18:00 | זום
17/12 - 18:00 - 20:00 | זום
17/12 - 20:00 - 22:00 | קמפוס לב
17/12 - 22:00 - 00:00 | זום
18/12 - 00:00 - 02:00 | זום
18/12 - 02:00 - 04:00 | זום
אלי אדלר
Techtopia
09/12 - 19:00 - 20:30 | קמפוס לב
09/12 - 20:30 - 22:00 | קמפוס לב
אליעזר גנסבורגר
JCT
02/12 - 19:00 - 20:30 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב
17/12 - 20:00 - 22:00 | קמפוס לב
אליעזר טויק
יורה מדע + JCT
02/12 - 20:30 - 22:00 | קמפוס לב
09/12 - 19:00 - 20:30 | קמפוס לב
16/12 - 13:00 - 15:00 | קמפוס לב
17/12 - 14:00 - 16:00 | קמפוס לב
אריא שטולמן
JCT
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב
אריה לובשיץ
עצמאי
02/12 - 19:00 - 20:30 | קמפוס לב
02/12 - 20:30 - 22:00 | קמפוס לב
09/12 - 19:00 - 20:30 | קמפוס לב
09/12 - 20:30 - 22:00 | קמפוס לב
16/12 - 13:00 - 15:00 | קמפוס לב
16/12 - 15:00 - 17:00 | קמפוס לב
16/12 - 17:00 - 19:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
17/12 - 10:00 - 12:00 | קמפוס לב
17/12 - 12:00 - 14:00 | קמפוס לב
17/12 - 14:00 - 16:00 | קמפוס לב
17/12 - 16:00 - 18:00 | קמפוס לב
17/12 - 18:00 - 20:00 | קמפוס לב
בריאן פולין
JCT
17/12 - 10:00 - 12:00 | קמפוס לב
גולן כרמי
JCT
02/12 - 19:00 - 20:30 | זום
09/12 - 19:00 - 20:30 | זום
17/12 - 10:00 - 12:00 | זום
ד"ר נח בל
JCT
16/12 - 19:00 - 21:00 | קמפוס לב
17/12 - 12:00 - 14:00 | קמפוס לב
דוד זימברקנופף
FalkorDB
09/12 - 19:00 - 20:30 | זום
16/12 - 15:00 - 17:00 | זום
16/12 - 17:00 - 19:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
17/12 - 10:00 - 12:00 | קמפוס לב
17/12 - 12:00 - 14:00 | קמפוס לב
17/12 - 14:00 - 16:00 | קמפוס לב
17/12 - 16:00 - 18:00 | קמפוס לב
17/12 - 18:00 - 20:00 | זום
דרור מוגהץ
JCT
ויקטור יומפולסקי
Cust2Mate
02/12 - 19:00 - 20:30 | קמפוס לב
02/12 - 20:30 - 22:00 | קמפוס לב
09/12 - 19:00 - 20:30 | קמפוס לב
09/12 - 20:30 - 22:00 | קמפוס לב
16/12 - 13:00 - 15:00 | קמפוס לב
16/12 - 15:00 - 17:00 | קמפוס לב
16/12 - 17:00 - 19:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב
16/12 - 23:00 - 01:00 | קמפוס לב
17/12 - 01:00 - 03:00 | קמפוס לב
17/12 - 10:00 - 12:00 | קמפוס לב
17/12 - 12:00 - 14:00 | קמפוס לב
17/12 - 14:00 - 16:00 | קמפוס לב
17/12 - 16:00 - 18:00 | קמפוס לב
17/12 - 18:00 - 20:00 | קמפוס לב
17/12 - 20:00 - 22:00 | קמפוס לב
17/12 - 22:00 - 00:00 | קמפוס לב
18/12 - 00:00 - 02:00 | קמפוס לב
18/12 - 02:00 - 04:00 | קמפוס לב
חנן כהו רו''ח
פרטי
17/12 - 20:00 - 22:00 | קמפוס לב
17/12 - 22:00 - 00:00 | קמפוס לב
טוביה אלבוים
emaze.ai
16/12 - 13:00 - 15:00 | קמפוס לב
יאיר גולדשטיין
JCT
02/12 - 19:00 - 20:30 | קמפוס לב
09/12 - 19:00 - 20:30 | קמפוס לב
16/12 - 13:00 - 15:00 | זום
16/12 - 15:00 - 17:00 | זום
16/12 - 17:00 - 19:00 | זום
16/12 - 19:00 - 21:00 | זום
יהודה בריקסמן
IAF
02/12 - 19:00 - 20:30 | קמפוס לב
02/12 - 20:30 - 22:00 | קמפוס לב
09/12 - 19:00 - 20:30 | קמפוס לב
09/12 - 20:30 - 22:00 | קמפוס לב
16/12 - 17:00 - 19:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב
16/12 - 23:00 - 01:00 | קמפוס לב
17/12 - 10:00 - 12:00 | קמפוס לב
17/12 - 12:00 - 14:00 | קמפוס לב
17/12 - 14:00 - 16:00 | קמפוס לב
17/12 - 16:00 - 18:00 | קמפוס לב
17/12 - 18:00 - 20:00 | קמפוס לב
17/12 - 20:00 - 22:00 | קמפוס לב
17/12 - 22:00 - 00:00 | קמפוס לב
18/12 - 00:00 - 02:00 | קמפוס לב
18/12 - 02:00 - 04:00 | קמפוס לב
יהונתן שקלים
FinTrap
16/12 - 13:00 - 15:00 | קמפוס לב
16/12 - 15:00 - 17:00 | קמפוס לב
16/12 - 17:00 - 19:00 | קמפוס לב
יהושע ווגל
CytoReason
17/12 - 18:00 - 20:00 | קמפוס לב
יהל גיאת
JCT
02/12 - 19:00 - 20:30 | קמפוס לב
16/12 - 17:00 - 19:00 | קמפוס לב
יוהן אלבז
משרד הבריאות - HMS
16/12 - 21:00 - 23:00 | קמפוס לב
יורם חדד
JCT
16/12 - 13:00 - 15:00 | קמפוס לב
יעקב נוימן
NetOp Cloud
02/12 - 19:00 - 20:30 | זום
09/12 - 19:00 - 20:30 | זום
16/12 - 17:00 - 19:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
17/12 - 10:00 - 12:00 | זום
17/12 - 12:00 - 14:00 | זום
17/12 - 14:00 - 16:00 | זום
17/12 - 18:00 - 20:00 | זום
יצחק גולדסטנד
CloudEx
17/12 - 10:00 - 12:00 | קמפוס לב
17/12 - 12:00 - 14:00 | קמפוס לב
17/12 - 14:00 - 16:00 | קמפוס לב
17/12 - 16:00 - 18:00 | קמפוס לב
17/12 - 18:00 - 20:00 | קמפוס לב
כפיר מתיתיהו
Places
02/12 - 20:30 - 22:00 | קמפוס לב
09/12 - 19:00 - 20:30 | קמפוס לב
09/12 - 20:30 - 22:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב
17/12 - 16:00 - 18:00 | קמפוס לב
17/12 - 18:00 - 20:00 | קמפוס לב
17/12 - 20:00 - 22:00 | קמפוס לב
מיכאל ג'מט
Ex-Intel
02/12 - 19:00 - 20:30 | זום
09/12 - 19:00 - 20:30 | זום
16/12 - 13:00 - 15:00 | זום
17/12 - 14:00 - 16:00 | זום
18/12 - 02:00 - 04:00 | זום
מני מאור
Elbit
17/12 - 16:00 - 18:00 | קמפוס לב
17/12 - 18:00 - 20:00 | קמפוס לב
17/12 - 20:00 - 22:00 | קמפוס לב
משה ימיני
Mobileye
02/12 - 20:30 - 22:00 | קמפוס לב
09/12 - 20:30 - 22:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
מתן פחימה
nRich
02/12 - 19:00 - 20:30 | קמפוס לב
02/12 - 20:30 - 22:00 | קמפוס לב
09/12 - 19:00 - 20:30 | קמפוס לב
09/12 - 20:30 - 22:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב
16/12 - 23:00 - 01:00 | קמפוס לב
נדב קוקורייב
Places
16/12 - 13:00 - 15:00 | קמפוס לב
עדיאל שליט
Crossriver
16/12 - 15:00 - 17:00 | קמפוס לב
ערן שלום
JCT
02/12 - 19:00 - 20:30 | קמפוס לב
09/12 - 20:30 - 22:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
17/12 - 16:00 - 18:00 | קמפוס לב
17/12 - 18:00 - 20:00 | קמפוס לב
צבי אליעזר ניר
IDF
02/12 - 19:00 - 20:30 | זום
02/12 - 20:30 - 22:00 | זום
09/12 - 19:00 - 20:30 | זום
09/12 - 20:30 - 22:00 | זום
16/12 - 13:00 - 15:00 | קמפוס לב
16/12 - 15:00 - 17:00 | קמפוס לב
16/12 - 17:00 - 19:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | זום
16/12 - 23:00 - 01:00 | זום
17/12 - 01:00 - 03:00 | זום
17/12 - 10:00 - 12:00 | זום
17/12 - 12:00 - 14:00 | זום
17/12 - 14:00 - 16:00 | זום
17/12 - 16:00 - 18:00 | זום
17/12 - 18:00 - 20:00 | קמפוס לב
17/12 - 20:00 - 22:00 | קמפוס לב
17/12 - 22:00 - 00:00 | קמפוס לב
18/12 - 00:00 - 02:00 | זום
18/12 - 02:00 - 04:00 | זום
שלום לויפר
JCT
17/12 - 10:00 - 12:00 | קמפוס לב
שמואל ווערס
JCT
17/12 - 10:00 - 12:00 | קמפוס לב
תמיר פייביש
IBM
16/12 - 17:00 - 19:00 | קמפוס לב
16/12 - 19:00 - 21:00 | קמפוס לב
16/12 - 21:00 - 23:00 | קמפוס לב

למי זה מיועד?

תוכנה

אלגורתימים / מערכות / אתרים / אפליקציות

מנהל עסקים

סקר שוק / מודל עסקי / פרזנטציה

תעשייה וניהול

אופטימיזציה / שיפור תהליכים / תיכון תוכנה

חשבונאות

מודל עסקי / היבטים פיננסים

סיעוד

היבטים רפואים

אלקטרוניקה

תיכון חומרה / בניית חומרה

אלקטרואופטיקה

חיישונים / פיזיקה

ביו אינפורמטיקה

היבטים רפואים / תוכנה

תקשורת

תקשורות / רשתות

המלצת המערכת: שלבו בקבוצותיכם כמה שיותר תחומי ידע רלוונטיים על מנת להגדיל את סיכויי ההצלחה!


סטודנטים יתחלקו לקבוצות כדי לבנות מוצר ופרזנטציה. 

אנו ממליצים שכל קבוצה תורכב מ:

  • 2-3 סטודנטים בעלי ידע טכנולוגי (תכנות וכדו' ו/או אלקטרוניקה באתגרים הרלוונטים) - מדעי המחשב / הנדסת תוכנה / הנדסת אלקטרוניקה / הנדסת אלקטרו אופטיקה.
  • סטודנט בעל ידע עסקי (לביצוע סקר שוק, כדאיות עסקית, פרזנטציה ועוד) - מנהל עסקים.
  • סטודנט בעל יכולת ניהול וניתוח תהליכים (הובלה של צוותים ובניית מודלים באתגרים בהם זה רלוונטי) - תעשייה וניהול.
  • 1-2 סטודנטים בעלי ידע בתחומים רפואים (לאתגרים הרלוונטים) - סיעוד.
  • 1-2 סטודנטים בעלי ידע בתחום הפיננסי (לאתגרים הרלוונטים) - חשבונאות.

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


אתגרים

סטודנטים יתחלקו לקבוצות כדי לבנות מוצר ופרזנטציה. 



הצצה לאתגרים מהאקתונים קודמים:


אתגרים נוספים יעלו בהמשך



לחצו על הכפתור בתחתית האתגר לצפייה בסרטון של מציג האתגר!

אתגרים נוספים יעלו כל הזמן במהלך השבועות הקרובים

בעיה

מופעי רחפנים (Drone Light Shows) מסתמכים באופן קריטי על היכולת למקם כל רחפן בנחיל בדיוק של סנטימטרים בודדים. הפתרון המקובל כיום הוא ניווט מבוסס RTK (Real-Time Kinematic), המספק דיוק זה על ידי תיקוני GPS. הבעיה המרכזית היא שטכנולוגיית RTK, כמו כל טכנולוגיית GPS, רגישה מאוד לחסימות (Jamming). ניתן לשבש מופע שלם באמצעים פשוטים וזולים יחסית. חסימת GPS גורמת לאובדן מיקום מיידי, להפסקת המופע, ולסכנה בטיחותית. נדרש פתרון ניווט חלופי, יציב ועמיד שאינו תלוי בלוויינים.

פיתרון

פיתוח אב-טיפוס של מערכת ניווט יחסית (Relative Navigation) קלת משקל וחסכונית בהספק. המערכת תספק מיקום תלת-ממדי בדיוק של סנטימטרים בודדים עבור כל רחפן בנחיל, ללא תלות בקליטת GPS/RTK. המערכת תתבסס על מדידת מרחקים מדויקת בין הרחפנים עצמם (Drone-to-Drone) ובינם לבין מספר "עוגנים" (Anchors) קרקעיים. הפתרון יאפשר לנחיל לשמור על המבנה המדויק שלו (Formation) גם במקרה של חסימת GPS מלאה, וישמש כמערכת גיבוי קריטית או אף כמערכת ניווט ראשית בסביבות "מבוססות קרקע" (Ground-Based Navigation).

רמזים

1. מומלץ להתבסס על טכנולוגיית UWB (Ultra-Wideband), המסוגלת למדוד מרחקים בין שני מכשירים (Nodes) בדיוק של סנטימטרים בודדים. זאת טכנולוגיה שמתבססת על שידורי RF וקיימת ב-AirTag. 2. ניתן ליישם אלגוריתם מיקום (Localization Algorithm) כגון Trilateration או Multilateration (MLAT), שבו כל רחפן מחשב את מיקומו היחסי על בסיס המרחק הידוע ממספר עוגנים (לפחות 4 עוגנים למיקום 3D יציב). 3. יש להתייחס לאתגר הסנכרון וקצב עדכון המיקום הגבוה הנדרש על ידי בקר הטיסה של הרחפן. 4. יש לחשוב על הארכיטקטורה: האם המיקום מחושב על הרחפן עצמו (Decentralized) או בתחנת קרקע (Centralized) ונשלח אליו בחזרה?

כלים

1. רכיבי UWB: מודולים מבוססי DW1000 (כגון DWM1000) או DW3000. 2. בקרים: ESP32 (מומלץ בשל יכולות ה-WiFi/Bluetooth והעיבוד שלו). 3. פלטפורמת פיתוח: Arduino IDE, ESP-IDF, או PlatformIO. 4. מידע וקוד פתוח: קיימות ספריות קוד פתוח ל-DW1000. 5. סיוע מצוותים אחרים: סטודנטים המשתתפים באתגר אחר מתמחים בחומרה זו ויכולים לספק ידע, סיוע טכני ודוגמאות קוד למימוש התקשורת הבסיסית עם הרכיב.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

פיתוח סוכן AI שמבצע מעקב והתכתבות מול גופים חיצוניים באופן אוטומטי, לפי הנחיות כלליות של המשתמש. הסוכן יוכל לפעול דרך ערוצים שונים – שיחות קוליות (עם זיהוי ודיבור טבעי), הודעות WhatsApp או SMS, דוא"ל, ועוד. ניתן לממש אותו במספר תרחישים: 1. הזמנת שירות (טכנאי, פיצה וכו') מבלי להמתין בטלפון 2. התנהלות והתכתבות אוטומטית מול מוסדות בירוקרטיים (כגון רשות המיסים, ביטוח לאומי וכו') 3. מעקב אחרי משימות מול אנשי צוות / פרויקט, כולל שליחת תזכורות והודעות

רמזים

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

כלים

- OpenAI API (או Claude, Gemini, וכו') - Twilio API – להתממשקות עם WhatsApp וטלפון - Gmail API / Outlook API – לשליחת ומעקב אחרי אימיילים - קוד פתוח של סוכני AI (כגון AutoGPT, CrewAI, OpenAgents) - Whisper / Coqui – לזיהוי דיבור בשיחות קוליות - TTS – ליצירת דיבור חוזר אוטומטי

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

פיתוח מערכת יישומית המשתמשת באלגוריתמים מתקדמים של מעקב מבוסס למידת מכונה (ML-based Tracking) כדי לפתור בעיה ספציפית ומשמעותית לבחירתכם. המערכת לא צריכה רק "לעקוב", אלא להשתמש במעקב כדי להפיק תובנות או לבצע פעולה. עליכם לבחור מודל מעקב מתקדם (כגון SAM2, CoTracker, TrackAnything, XMem וכדומה) וליישם אותו בתרחיש שמאתגר מעקבים קלאסיים. דוגמאות ליישום: מערכת לניתוח התנהגות קהל צפוף, כלי לעריכת וידאו אוטומטית המוחק אובייקט דינמי, בקרת איכות בפס ייצור של מוצרים גמישים, או ניתוח ביו-מכאני של ספורטאי בזמן אמת.

רמזים

1. בחירת המודל: בעוד ש-SAM2 הוא דוגמה מצוינת ליכולות סגמנטציה, ישנם מודלים המתמחים במעקב אחר נקודות (Point Tracking) כמו CoTracker או TAPIR. בחרו את המודל המתאים לבעיה (האם חשוב לכם קווי המתאר המדויקים או התנועה במרחב?). 2. אתגר הזיכרון: כיצד המערכת שלכם מתמודדת עם אובייקט שיצא מהפריים וחזר לאחר מספר שניות? (Re-Identification). 3. אינטראקציה: חשבו על דרך בה המשתמש מגדיר את האובייקט למעקב (למשל: הקלקה ראשונית, הנחיה טקסטואלית, או זיהוי אוטומטי של חריגות). 4. ביצועים: נסו להתייחס לסוגיית זמן הריצה. האם הפתרון שלכם ישים לזמן אמת (Real-time) או מיועד לעיבוד Offline?

כלים

1. Python 2. ספריות ML מובילות: PyTorch / TensorFlow / JAX 3. מודלים למעקב וסגמנטציה: SAM2, CoTracker, Track-Anything, DeepSORT, YOLO-World 4. OpenCV לעיבוד תמונה 5. סביבת הרצה עם GPU (כגון Google Colab או שרת מקומי חזק) 6. דאטה-סטים לאימון/בדיקה: COCO, DAVIS, MOTChallenge או צילומים מקוריים שלכם.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

ערים חכמות ומתקנים אסטרטגיים מרושתים כיום באלפי מצלמות אבטחה. האתגר המרכזי אינו רק זיהוי אובייקט במצלמה בודדת, אלא היכולת לייצר רצף מעקב (Continuity) אחר אובייקט (אדם חשוד, רכב ספציפי) הנע במרחב ועובר בין שדות ראייה של מצלמות שונות. בפועל, החפיפה בין המצלמות היא לרוב מינימלית (10%-20%), מה שמקשה על המערכת להבין שאובייקט שיצא ממצלמה א' הוא אותו אובייקט שנכנס למצלמה ב'. שינויים בזווית הצילום, תאורה, והסתרה רגעית גורמים לאיבוד המעקב ולקבלת תמונת מצב מקוטעת המקשה על קבלת החלטות.

פיתרון

פיתוח מערכת ראייה ממוחשבת המבצעת 'מסירה' (Handover) של אובייקטים בין מצלמות סמוכות. המערכת תקבל זרמי וידאו ממספר מצלמות, תזהה אובייקטים ותעניק להם מזהה ייחודי (ID). האתגר הוא לשמר את ה-ID הזהה כאשר האובייקט עובר בין המצלמות באזור החפיפה המצומצם. הפתרון צריך לכלול מודל Re-ID (זיהוי מחדש) המבוסס על מאפיינים ויזואליים ומרחביים, ולדעת לחזות את מיקום האובייקט במצלמה הבאה על סמך מהירות וכיוון התנועה שלו, ובכך לאפשר מעקב רציף ואוטומטי בזמן אמת.

רמזים

1. שימוש באלגוריתמים של Re-Identification המבוססים על חתימה ויזואלית (צבע, טקסטורה, פרופורציות) ולא רק על זיהוי פנים/לוחית רישוי. 2. חישוב וחיזוי מסלול (Trajectory Prediction) באמצעות Kalman Filter כדי להעריך מתי ואיפה האובייקט יופיע במצלמה הבאה. 3. שימוש ב-Homography כדי למפות את הקשר הגיאומטרי בין המצלמות ולהבין אילו פיקסלים במצלמה א' חופפים לפיקסלים במצלמה ב'. 4. התייחסות לשינויי סקאלה (Scale) - אובייקט רחוק במצלמה אחת עשוי להיראות קרוב וגדול במצלמה השנייה.

כלים

1. שפות תכנות: Python, C++. 2. ספריות ראייה ממוחשבת: OpenCV. 3. מודלים לזיהוי ומעקב: YOLO (v5/v8), DeepSORT, StrongSORT, FairMOT, SAM2. 4. ספריות למידה עמוקה: PyTorch, TensorFlow. 5. דאטה-סטים לאימון: Market-1501, DukeMTMC (לצורך אימון מודל Re-ID). 6. חומרה: מומלץ שימוש ב-GPU חזק (NVIDIA CUDA) לעיבוד בזמן אמת של מספר ערוצי וידאו.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

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

רמזים

1. חומרים משני פאזה (PCM): חומרים האוגרים ומשחררים חום בתהליך התמצקות/התכה, הניתנים לשימוש חוזר. 2. ריאקציות כימיות הפיכות: שימוש בתמיסות (כגון סודיום אצטט) שניתן "לאתחל" אותן מחדש בקלות. 3. גופי חימום חשמליים יעילים: שימוש בסיבי פחמן או ננו-טכנולוגיה המופעלים ע"י סוללות ליתיום קלות וצפופות אנרגיה. 4. בטיחות: מנגנון למניעת כוויות (טרמוסטט מכני או אלקטרוני) הוא קריטי, שכן הפצוע אינו חש כאב או חום באותה עצימות. 5. אינטגרציה: האם המוצר הוא שמיכה, וסט, או רפידות המתחברות לאזורי ליבה?

כלים

1. חומרים מתקדמים (טקסטיל חכם, חומרים מבודדים תרמית). 2. בקרים זעירים (Arduino/ESP32) לניהול צריכת אנרגיה ובקרת טמפרטורה. 3. תוכנות CAD לתכנון המוצר והמארז. 4. סוללות בצפיפות אנרגיה גבוהה (Lipo/Li-ion). 5. חיישני טמפרטורה.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

פיתוח פתרון תוכנה מבוסס עיבוד תמונה (Computer Vision) המשתמש במצלמה אחת או יותר המותקנות על כלי השיט. המערכת תצלם את השמיים, תזהה את בסיס הענן, ותחשב את גובהו מעל פני הים בזמן אמת. הפתרון נדרש להיות מסוגל לפצות על תנודות הספינה (Roll, Pitch, Yaw), לבודד את העננים הרלוונטיים, ולספק פלט מספרי ברמת דיוק גבוהה, תוך שימוש בחומרה נגישה וזולה יחסית בהשוואה לפתרונות הלייזר הקיימים.

רמזים

1. שימוש בראייה סטריאוסקופית (Stereo Vision) באמצעות שתי מצלמות במרחק ידוע ליצירת מפת עומק. 2. ניתוח היטל צל הענן על פני הים בשילוב עם זווית השמש הידועה (לפי שעה ומיקום GPS) לחישוב טריגונומטרי. 3. שימוש בטכניקת Motion Parallax המנצלת את תנועת הספינה עצמה כדי לחשב מרחק באמצעות מצלמה בודדת. 4. זיהוי ונעילה על קו האופק (Horizon Detection) כעוגן לייצוב התמונה וחישובי הזוויות. 5. סיווג סוג הענן באמצעות למידת מכונה כדי לשערך טווחי גובה אופייניים כבסיס לחישוב.

כלים

Python OpenCV (לעיבוד תמונה וזיהוי קו אופק) TensorFlow / PyTorch (לאימון מודלים לזיהוי עננים) ספריות לחישובים גיאומטריים וטריגונומטריים נתוני GPS ו-IMU (ג'יירוסקופ/מד תאוצה) לסימולציית תנועת הספינה מאגרי תמונות עננים ציבוריים (כגון SWIMCAT או CCD) לאימון מכשיר ליצירת אדים לצורך דימוי ענן ציוד לייזר

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

פיתוח שכבת עיבוד אלגוריתמית המנתחת הדמאות SAR (Synthetic Aperture Radar) כדי לייצר מפת עומקים (בתימטריה) וטופוגרפיה של קרקעית הים. הפתרון צריך להתבסס על זיהוי וניתוח של שינויים בטקסטורת פני המים (כגון אדוות וגלים) המושפעים מהזרימה מעל מכשולים תת-ימיים. המערכת צריכה לקלוט נתוני SAR גולמיים או מעובדים חלקית, לנקות רעשים, ולתרגם את חתימת המכ"ם למודל תלת-ממדי של הקרקעית ברזולוציה גבוהה, תוך חיסכון משמעותי בעלויות ובזמן לעומת סקרים ימיים פיזיים.

פיתרון

פיתוח שכבת עיבוד אלגוריתמית המנתחת הדמאות SAR (Synthetic Aperture Radar) כדי לייצר מפת עומקים (בתימטריה) וטופוגרפיה של קרקעית הים. הפתרון צריך להתבסס על זיהוי וניתוח של שינויים בטקסטורת פני המים (כגון אדוות וגלים) המושפעים מהזרימה מעל מכשולים תת-ימיים. המערכת צריכה לקלוט נתוני SAR גולמיים או מעובדים חלקית, לנקות רעשים, ולתרגם את חתימת המכ"ם למודל תלת-ממדי של הקרקעית ברזולוציה גבוהה, תוך חיסכון משמעותי בעלויות ובזמן לעומת סקרים ימיים פיזיים.

רמזים

1. התבססות על הידרודינמיקה: מכ"ם אינו רואה דרך המים, אלא מודד את החזר פני השטח. עליכם למצוא את הקורלציה בין הטופוגרפיה התת-ימית לבין זרמי המים שיוצרים תבניות גלים (Roughness) על פני השטח הנראות ב-SAR. 2. שימוש ב-Deep Learning: אימון מודל על בסיס אזורים בהם הטופוגרפיה ידועה (Ground Truth מסונאר) כדי ללמוד את הקשר בין תמונת ה-SAR לעומק המים. 3. ניקוי רעשים (Speckle reduction): הדמאות SAR הן רועשות מטבען, נדרש עיבוד מקדים לשיפור איכות האות. 4. התחשבות במשתנים סביבתיים: מהירות רוח וכיוון הזרם משפיעים על התוצאה.

כלים

1. נתוני לוויין פתוחים: Sentinel-1 (ESA), Iceye, TerraSAR-X (דוגמאות). 2. ספריות עיבוד תמונה ו-GIS: GDAL, Rasterio, OpenCV, QGIS. 3. כלי SAR ייעודיים: SNAP (Sentinel Application Platform). 4. סביבות פיתוח ושפות: Python, MATLAB, C++. 5. ספריות למידת מכונה: TensorFlow, PyTorch, Keras.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

פיתוח פלטפורמת Data Fusion (היתוך מידע) המייצרת "מפת חום" תלת-ממדית של אתר ההרס, המבוססת על הצלבת נתונים חיצוניים ופנימיים. המערכת תדע להתממשק (באמצעות API או סימולציה של נתונים) למאגרי מידע של תשתיות לאומיות: משיכת נתוני איכון סלולריים (Triangulation) דקות לפני האירוע, ניתוח דפוסי צריכת חשמל מונים חכמים (Smart Meters) לזיהוי דירות פעילות, וסטטוס חיבורי רשת (Wi-Fi). האלגוריתם ישקלל את הנתונים הללו יחד עם המבנה ההנדסי של הבניין (לפני ואחרי הקריסה) כדי להצביע על "כיסים" בהם סביר להניח שישנם לכודים, גם אם אינם משדרים כרגע אות מצוקה אקטיבי.

רמזים

1. "חתימת חיים דיגיטלית": זיהוי הרגע המדויק שבו מכשירים הפסיקו לשדר. הפסקת שידור פתאומית של 5 טלפונים באותה נקודה מעידה על מיקום קריטי. 2. מונים חכמים (Smart Grid): דירה שצרכה חשמל בעומס גבוה (מזגן, דוד, תאורה) דקות לפני הקריסה היא אינדיקטור חזק לנוכחות אדם, לעומת דירה עם צריכת "standby". 3. נתוני IoT ו-Wearables: אינטגרציה עם ענני בריאות (כגון Apple Health או Garmin) למשיכת נתוני דופק אחרונים שסונכרנו לענן לפני אובדן הקשר. 4. ניתוח עומסים ברשת הסלולרית: לא רק מיקום, אלא ניתוח עומס על אנטנות ספציפיות שיכול להעיד על התקהלות באזור מסוים במבנה (למשל בחדר מדרגות) רגע לפני האירוע. 5. פרטיות ורגולציה: תכנון מנגנון "Break Glass" המאפשר גישה לנתונים פרטיים רק בהינתן הכרזה על מצב חירום, תוך שמירה על אבטחת מידע.

כלים

1. מחוללי דאטה (Mock Data Generators) ליצירת נתוני סלולר/חשמל פיקטיביים לצורך ההאקתון. 2. כלי Big Data (Spark, Hadoop) לעיבוד כמויות גדולות של לוגים בזמן אמת. 3. מסדי נתונים מרחביים (PostGIS) למיפוי הנתונים על גבי תוכניות מבנה. 4. ספריות Python לניתוח נתונים (Pandas, NumPy). 5. כלי ויזואליזציה (Mapbox, Cesium) להצגת השכבות השונות למחלץ. 6. APIs לסימולציה של רשתות IoT ורשתות סלולר.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

בעולם פיתוח התוכנה המודרני (CI/CD), קצב השחרור של גרסאות חדשות הוא מסחרר. צוותי פיתוח ו-QA נדרשים לוודא שהממשק (UI) מתפקד כראוי בכל גרסה, אך יצירת בדיקות אוטומטיות היא תהליך איטי, יקר ומורכב לתחזוקה. בדיקות ידניות גוזלות זמן אדם יקר ואינן סקיילביליות. מצד שני, כתיבת סקריפטים לאוטומציה (בכלים כמו Selenium או Playwright) דורשת מיומנות תכנות גבוהה. הבעיה מחמירה כאשר מזהים בממשק (Selectors כמו ID או CSS Classes) משתנים, מה שגורם לסקריפטים "להישבר" תכופות ולצוותים לבזבז זמן רב על תחזוקת בדיקות במקום על בדיקת לוגיקה עסקית חדשה. קיים פער משמעותי בין תרחיש הבדיקה כפי שהוא מנוסח בשפה טבעית (למשל: "הוסף מוצר לעגלה") לבין הקוד הנדרש לביצועו.

פיתרון

פיתוח כלי חכם (AI-Driven Test Generator) המקבל כקלט הנחיה טקסטואלית בשפה טבעית (Prompt) המתארת תרחיש שימוש, ומתרגם אותה באופן אוטומטי לסקריפט בדיקות תקין ורצה. המערכת תאפשר למשתמש (גם ללא רקע בפיתוח) לכתוב תרחיש כמו "הכנס לאתר הדמו, הוסף משימה חדשה בשם 'לקנות חלב', סמן אותה כבוצעה וודא שהמונה מראה 0 פריטים". הכלי ינתח את הפרומפט, יבין את הפעולות הנדרשות ואת סדרן, ויג'נרט קוד (למשל ב-Playwright) שמבצע את הפעולות על הדפדפן בזמן אמת. הפתרון צריך לדעת להתמודד עם זיהוי אלמנטים בצורה חכמה (לפי משמעות ותוכן ולא רק לפי מיקום טכני), ובכך לייצר בדיקות יציבות ועמידות בפני שינויים קוסמטיים בממשק.

רמזים

1. שימוש במודלי שפה גדולים (LLMs): מומלץ להשתמש ב-OpenAI או Azure OpenAI כדי לפרק את הפרומפט המילולי לשלבים לוגיים (למשל, המרה לפורמט ביניים כמו JSON או DSL שמתאר את הפעולות: Action: Click, Target: 'Submit Button'). 2. אסטרטגיית סלקטורים חכמה: בעת יצירת הקוד, הימנעו משימוש בנתיבים שבירים כמו XPath ארוך או CSS Classes אקראיים. הנחו את המודל להעדיף סלקטורים סמנטיים נגישים (Accessibility Selectors) כגון getByRole, getByLabel, או getByText, שמחקים את האופן שבו משתמש אנושי תופס את המסך. 3. ולידציה (Assertions): שימו לב שהפרומפט כולל גם דרישה לאימות ("וודא שמופיע..."). הסקריפט חייב לכלול פקודות Assertions מתאימות לווידוא הצלחת הבדיקה. 4. מנגנון תיקון עצמי (Self-Healing): רעיון למתקדמים - אם הסקריפט נכשל בזיהוי אלמנט, המערכת יכולה לנתח את ה-DOM מחדש ולנסות אסטרטגיית זיהוי חלופית בזמן אמת. 5. דוגמה לתרחיש בסיסי לבדיקה: "גלוש ל-https://demo.playwright.dev/todomvc, הוסף משימה 'לקנות חלב', סמן אותה כבוצעה, ואמת שמופיע הטקסט '0 items left'".

כלים

1. Generative AI APIs: Azure OpenAI, OpenAI (GPT-4/3.5), Claude או מודלים רלוונטים אחרים מ-Hugging Face.. 2. Test Automation Frameworks: Playwright, Selenium, Cypress, Puppeteer. 3. Backend Languages: Python, Node.js. 4. Libraries: LangChain (לניהול השיחה עם ה-LLM), Beautiful Soup (לניתוח HTML סטטי במידת הצורך).

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

ארגונים רבים מתמודדים עם מחסור בחוקרי אבטחה (Security Researchers) וצוותי אבטחה מצומצמים. במצב זה, ארכיטקטי האבטחה נאלצים להעביר משימות של אימות ולידציה (Security Validation) לצוותי הפיתוח והבדיקות. לצוותים אלו, לרוב, אין את הרקע הטכני העמוק או את ה"חשיבה ההתקפית" הנדרשת לביצוע בדיקות אבטחה מורכבות. נוצר פער משמעותי: ארכיטקט האבטחה מגדיר דרישה ברמה גבוהה (למשל: "לוודא עמידות ל-SQL Injection"), אך המפתחים זקוקים לצעדים קונקרטיים וסקריפטים ברורים כדי לבדוק זאת בפועל. פער זה יוצר צוואר בקבוק, גורם לבדיקות ליפול בין הכיסאות או להתבצע באופן שטחי, ומעלה את הסיכון לחדירת פרצות אבטחה למוצר.

פיתרון

פיתוח מערכת מבוססת GenAI שתשמש כ"שכבת תרגום" חכמה בין דרישות אבטחה מופשטות לבין תוכניות בדיקה (Test Plans) מעשיות. המערכת תקבל כקלט דרישת אבטחה בשפה חופשית (למשל: "בדוק את ה-API Endpoint הזה עבור פרצות הרשאות") או אפילו תנתח קטעי קוד. באמצעות מנוע LLM, המערכת תייצר באופן אוטומטי תוכנית בדיקות אבטחה מפורטת. התוכנית תכלול צעדים מדויקים לביצוע, פקודות ספציפיות להרצה (כמו פקודות curl, קטעי Python), דוגמאות ל-Payloads זדוניים, ותיאור ברור של התוצאות הצפויות (Expected Results) במקרה של הצלחה או כישלון של הבדיקה. המטרה היא להעצים את צוותי הפיתוח ולאפשר להם לבצע בדיקות אבטחה בסיסיות עד בינוניות באופן עצמאי ויעיל.

רמזים

1. מומלץ לאפשר למערכת להתממשק עם מודלי שפה הרצים באופן מקומי (Local LLMs) באמצעות כלים כמו Ollama. זאת כדי לשמור על סודיות ופרטיות קוד המקור של הארגון ולהימנע משליחתו לשירותי ענן חיצוניים. 2. ניתן לבחון את קוד הבסיס ודוגמאות הפעולה שסופקו במאגר ה-GitHub של האתגר כדי להבין את ארכיטקטורת הבסיס ולקבל כיוון התחלתי. 3. יש לשים דגש על איכות הפלט: הצעדים חייבים להיות ברורים, מדויקים, וקלים לביצוע עבור מפתח שאינו איש אבטחה. 4. כדאי לחשוב על ממשק משתמש נוח. לדוגמה: תוסף (Extension) לסביבת פיתוח כמו VSCode, שיאפשר למפתחים לבקש ולקבל תוכניות בדיקה ישירות מה-IDE. 5. יש להתייחס גם ליכולת האוטומציה – לא רק לייצר את הצעדים, אלא אולי גם לייצר סקריפט בדיקה שלם שהמפתח יוכל להריץ בלחיצת כפתור.

כלים

* Python * Ollama (להרצת מודלים מקומיים) * VSCode (כסביבת פיתוח או כפלטפורמה לתוסף) * אופציונלי: מפתחות API למודלי ענן (כגון OpenAI, Google Gemini, Anthropic Claude) לצורך השוואה או יכולות מורחבות. * מאגר GitHub של האתגר (לעיון בקוד בסיס): https://github.com/Liramic/GenAI-Automated-Security-Test-Creator/tree/main

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

אחד הכאבים הגדולים ביותר בפיתוח תוכנה הוא הפער התמידי בין הקוד בפועל לבין התיעוד שלו. ברוב הארגונים, מחזורי הפיתוח המהירים (CI/CD) גורמים לכך שמסמכי האפיון, ארכיטקטורת המערכת (HLD/LLD), ותיקי אבטחת המידע הופכים ללא רלוונטיים רגע אחרי שנכתבו, או שכלל לא נכתבים מפאת חוסר זמן. מצב זה יוצר "חוב תיעודי" (Documentation Debt) מסוכן: צוותי הפיתוח מתקשים לבצע חפיפה לעובדים חדשים, צוותי האבטחה מתקשים לבצע סקרי סיכונים (Security Reviews) על בסיס מידע עדכני, ואין תמונת מצב אמיתית של זרימת המידע וההגנות הקיימות במוצר. התוצאה היא "קופסה שחורה" שקשה לתחזק וקשה עוד יותר לאבטח.

פיתרון

פיתוח מערכת מבוססת סוכני AI (Autonomous Agents) המשתלבת בתהליכי הפיתוח וה-SSDLC הארגוניים, ומייצרת תיעוד חי, דינמי ומדויק באופן אוטומטי. המערכת תבצע "הנדסה לאחור" (Reverse Engineering) לוגית: היא תסרוק את הקוד (Repository), את קבצי הקונפיגורציה של התשתיות (IaC), את הלוגים של תהליכי ה-CI/CD ואת מסמכי התכנון הגולמיים (כגון כרטיסי Jira או עמודי Confluence). על בסיס מידע זה, הסוכנים ימלאו באופן אוטומטי תבניות תיעוד תקניות, הכוללות: תרשימי ארכיטקטורה עדכניים, מיפוי זרימת נתונים (Data Flow Diagrams), רשימת נכסים ורכיבי צד-שלישי, ובקרות אבטחה המוטמעות בקוד. התוצר הוא "ספר מוצר" שמתעדכן בכל גרסה (Documentation as Code).

רמזים

1. סוכנים מתמחים (Multi-Agent System): יצירת סוכן "ארכיטקט" שמנתח מבנה, סוכן "אבטחה" שמזהה בקרות והצפנות, וסוכן "אינטגרציה" שמחבר את המידע למסמך אחד. 2. ניתוח סטטי ודינמי: שימוש ב-AI לא רק לקריאת טקסט, אלא להבנת הלוגיקה של הקוד (Code Understanding) וזיהוי קשרים בין מיקרו-שירותים. 3. עדכון גרסאות (Diff Analysis): המערכת צריכה לדעת לנתח את ה-Diff בין גרסאות ולעדכן רק את הסעיפים הרלוונטיים בתיעוד, תוך סימון השינויים. 4. פרטיות ואבטחה (Privacy Preserving AI): הקפדה שהקוד הארגוני לא ידלוף למודלים ציבוריים (שימוש ב-Local LLMs או Enterprise APIs). 5. אינטגרציה ל-SSDLC: התיעוד צריך להיות חלק מתהליך ה-Build, כך שכישלון בייצור תיעוד עדכני יתריע למפתחים. 6. ויזואליזציה: יצירה אוטומטית של דיאגרמות (למשל ב-Mermaid.js או PlantUML) מתוך ניתוח הקוד.

כלים

1. מודלי שפה לקוד: StarCoder, CodeLlama, GPT-4 Turbo (עם הקשר רחב) או מודלים רלוונטים אחרים מ-Hugging Face. 2. ספריות לניתוח קוד: Tree-sitter, LangChain (לניהול הקשר וסוכנים). 3. כלי Documentation-as-Code: MkDocs, Sphinx, Hugo. 4. כלי דיאגרמות מקוד: Mermaid.js, Graphviz. 5. פלטפורמות CI/CD: Jenkins, GitLab CI, GitHub Actions.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

פיתוח תוכנה מודרני מסתמך באופן מסיבי על שימוש ברכיבי קוד פתוח (Open Source) וספריות חיצוניות כדי להאיץ את קצב הפיתוח. עם זאת, שימוש לא מבוקר ברכיבים אלו חושף ארגונים לסיכונים משמעותיים בשני מישורים עיקריים: משפטי ואבטחת מידע. בהיבט המשפטי, רישיונות מסוימים (כגון GPL) עשויים לחייב את הארגון לחשוף את הקוד הקנייני שלו, מה שעלול להוביל לאובדן קניין רוחני. בהיבט האבטחתי, ספריות עשויות להכיל חולשות אבטחה (CVEs), קוד זדוני, או להיות נטושות ללא תחזוקה. כיום, תהליך האישור הוא לרוב ידני, איטי ומהווה "צוואר בקבוק" שמעכב את הפיתוח, או לחלופין – המפתחים עוקפים את התהליך ומכניסים סיכונים לפרודקשן ללא פיקוח.

פיתרון

פיתוח פלטפורמה ארגונית חכמה המבוססת על אוטומציה ובינה מלאכותית (AI Agents), שתשמש כ"שומר סף" דיגיטלי עבור כל ספרייה חדשה שמבקשים להכניס לקוד הארגוני. המערכת תזהה באופן אוטומטי בקשות להוספת ספריות (דרך קבצי Manifest או Pull Requests), תבצע ניתוח עומק באמצעות AI ותקבל החלטה או תספק המלצה לגורם האנושי. הפתרון צריך לכלול אנליזה של הטקסט המשפטי של הרישיון וסיווגו, סריקת אבטחה מקיפה לאיתור חולשות ידועות, בדיקת מוניטין המפתחים ותדירות העדכונים, והתאמה טכנולוגית לאופי הפרויקט. המטרה היא ליצור תהליך Approval מהיר, אמין ואוטומטי ככל הניתן, שמונע כניסת קוד מסוכן לפרודקשן.

רמזים

1. שימוש בסוכני AI (Agentic Workflow): יצירת מספר "סוכנים" מתמחים – סוכן משפטי המנתח רישיונות, סוכן אבטחה הסורק חולשות, וסוכן איכות קוד. 2. הנדסת פרומפטים (Prompt Engineering): הגדרה מדויקת של פרומפטים כדי שה-LLM ידע לחלץ את סוג הרישיון המדויק (Permissive vs. Copyleft) גם מקבצי טקסט לא מובנים. 3. אינטגרציה לתהליכי CI/CD: המערכת צריכה להיות מסוגלת לחסום Build או Merge אם מתגלה ספרייה בעייתית. 4. ניתוח "שרשרת האספקה": בדיקה לא רק של הספרייה הישירה, אלא גם של התלויות (Dependencies) שהיא מושכת איתה. 5. ניהול "רשימה לבנה/שחורה": המערכת צריכה ללמוד מאישורים קודמים ולנהל מאגר ידע ארגוני של ספריות מאושרות. 6. ממשק צ'אט למפתח: בוט שמסביר למפתח מדוע הספרייה נדחתה ומציע חלופות בטוחות יותר.

כלים

1. מודלי שפה (LLMs): OpenAI GPT-4, Claude 3, Llama 3 (עבור ניתוח טקסט וקבלת החלטות). 2. פריימוורקים לאייג'נטים: LangChain, AutoGen, CrewAI. 3. מאגרי מידע לאבטחה: NVD (National Vulnerability Database), OSV (Open Source Vulnerabilities). 4. כלי ניהול חבילות: npm, pip, maven, gradle (לניתוח קבצי תלות). 5. כלי פיתוח: Python, Node.js, GitHub Actions / GitLab CI.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

פיתוח מערכת מבוססת סוכן בינה מלאכותית (AI Agent) שמבצעת אוטומציה לתהליך בדיקת הנאותות (Due Diligence) הראשוני. המערכת תקלוט את חומרי הסטארטאפ, תחלץ מידע קריטי (שמות מייסדים, בעיה, פתרון, טכנולוגיה, שלב גיוס, שווי מבוקש), ותבצע מחקר עומק עצמאי באינטרנט: בדיקת רקע וניסיון של המייסדים, איתור מתחרים ישירים ועקיפים, והשוואת הערכות שווי וגיוסים אחרונים בתחום. התוצר הסופי יהיה דוח מקיף המציג למשקיע את נקודות החוזק והחולשה, דגלים אדומים, והמלצות להעמקה, כולל ממשק צ'אט המאפשר למשקיע לתשאל את הסוכן על המיזם באופן חופשי.

רמזים

1. מומלץ להשתמש בארכיטקטורת RAG (Retrieval-Augmented Generation) כדי לאפשר למודל לענות במדויק על סמך המסמכים שהוגשו ולמנוע המצאות (Hallucinations). 2. הגדירו היטב את הפרמטרים לבדיקה: ניסיון קודם של המייסדים (Scraping של לינקדאין), בדיקת גודל שוק (TAM/SAM/SOM) מול דוחות חיצוניים, וזיהוי מתחרים שלא הוזכרו במצגת. 3. נסו לייצר ציון התאמה (Score) המשקלל את כל הפרמטרים ומסייע בתיעדוף המיזמים. 4. חשבו על חווית המשתמש: כיצד להציג את המידע בצורה שתחסוך למשקיע זמן קריאה (למשל: תקציר מנהלים, גרף מתחרים). 5. כבונוס: אפשרו למערכת להשוות את הסטארטאפ למיזמים אחרים המתחרים באותו האקתון או נמצאים בפורטפוליו של הקרן.

כלים

Python, LangChain / LlamaIndex (לניהול הסוכן), OpenAI GPT-4 / Claude 3 API (לניתוח טקסט והסקת מסקנות), Vector Database (כגון Pinecone, Milvus או Weaviate), ספריות לפענוח PDF (כגון PyPDF2 או Unstructured), כלי Web Scraping (כגון Selenium, Playwright או Tavily לחיפוש מתקדם), Streamlit / React (לבניית ממשק המשתמש).

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

פלטפורמת Snapio.ai מייצרת תמונות וסרטונים מקצועיים למוצרים מסחריים על בסיס קלט (תמונות) שהמשתמש מעלה. המערכת משרשרת מודלי AI מתקדמים שונים בהתאם לתוצאה הרצויה (לדוגמה, תמונת אווירה, סרטון 360 מעלות, וכו'). הצלחת התוצר הסופי תלויה באופן קריטי באיכות והתאמת הקלט למשימה הספציפית. למשל, כדי ליצור וידאו 360° מוצלח, תמונת הקלט חייבת לכלול את מרבית הפרטים והזוויות של המוצר. כיום, משתמשים רבים מעלים קלט חסר, לא מתאים, או באיכות נמוכה, מה שמוביל לתוצאות שאינן עקביות, אינן חדות, או אינן מדויקות. חסר מנגנון מקדים שמוודא את איכות הקלט *ביחס למשימה הנדרשת*.

פיתרון

פיתוח מנגנון אימות (Validation) חכם שיפעל כשער כניסה לפני הרצת המודלים. מנגנון זה יזהה באופן אוטומטי קלט חסר או לא מתאים למשימה שהמשתמש בחר. התהליך יכלול: 1. ניתוח התוצאה הרצויה: הבנה אוטומטית של המשימה (למשל, "יצירת וידאו 360") ומהם הדרישות ההכרחיות מהקלט כדי לבצע אותה בהצלחה. 2. אימות הקלט: בדיקה שהקלט שהמשתמש העלה אכן עומד בסטנדרטים הנדרשים (למשל, האם קיימות מספיק זוויות של המוצר? האם הרקע נקי? האם הרזולוציה מספקת?). 3. הנחיית משתמש: במידה והקלט אינו עומד בדרישות, המערכת תפיק הודעה מסודרת וברורה למשתמש, תסביר מה נדרש לשפר בקלט (למשל, "אנא העלה תמונה המציגה גם את גב המוצר") וכיצד לעשות זאת. מטרת הפתרון היא להבטיח שהמודלים יקבלו קלט איכותי בלבד, שיוביל לתוצאות עקביות ומדויקות.

רמזים

* הפתרון חייב להיות גנרי ודינמי. הלוגיקה של האימות צריכה להשתנות בהתאם למשימה (התוצאה הרצויה) שהמשתמש בחר. אימות לתמונת פרופיל שונה מאימות לסרטון 360. * יש לבחון מודלים שונים, תוצאות שונות וסוגי קלט שונים ככל הניתן כדי לוודא כיסוי מרבי של מקרי קצה. * כיצד המערכת תזהה "חוסר פרטים"? ניתן לחשוב על שימוש במודלי Computer Vision (כמו זיהוי אובייקטים, סגמנטציה, או השוואת מאפיינים) כדי להעריך את התמונה שהועלתה. * כיצד תנוסח ההנחיה למשתמש? חשבו על ממשק ידידותי (אולי אפילו ויזואלי) שיסביר למשתמש בדיוק מה חסר בתמונה שלו.

כלים

* גישה מלאה לפלטפורמת snapio.ai. * טוקנים (קרדיטים) לשימוש חופשי בפלטפורמה לצורך בחינת קלטים ותוצאות. * ניתן להשתמש בספריות Computer Vision (כגון OpenCV) או מודלי ML/AI לבדיקת התמונות.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

פיתוח פלטפורמת מודיעין עסקי המבצעת ניטור רציף ואוטומטי של הנכסים הדיגיטליים (אתרי אינטרנט, דפי נחיתה, רשתות חברתיות) של חברות הפורטפוליו. הפתרון יכלול: 1. סורק (Crawler) חכם שישמור גרסאות של אתרי החברות לאורך זמן. 2. מנוע השוואה המזהה שינויים בתוכן ובמסרים (תוך התעלמות משינויים טכניים או עיצוביים זניחים). 3. רכיב בינה מלאכותית (LLM) שינתח את מהות השינוי: המערכת תדע להסביר למשקיע בשפה טבעית מה השתנה באסטרטגיית החברה (לדוגמה: "החברה שינתה את המסר השיווקי שלה מהגנה היקפית להגנה מבוססת ענן"). 4. דשבורד והתראות חכמות שיציפו למשקיע תובנות על מגמות, כגון אימוץ טרנדים חדשים (כמו AI), שינוי מודל תמחור, או פנייה לסקטורים חדשים, וימליצו על פעולת המשך (כגון יצירת קשר עם היזם לבירור).

רמזים

- הבחנה בין עיקר לטפל: האתגר המרכזי הוא לא רק לזהות שבוצע שינוי (Diff), אלא להבין את המשמעות הסמנטית שלו. שינוי של "About Us" הוא קריטי יותר משינוי ב-Footer. - ניתוח סנטימנט וטרנדים: שימוש במודלי שפה כדי לזהות מילות מפתח חדשות שנכנסו לשיח של החברה (למשל: Generative AI, Enterprise Ready). - תדירות דגימה: מנגנון שיודע מתי לסרוק את האתרים כדי לא להעמיס, אך להיות מעודכן מספיק. - היסטוריה וקונטקסט: היכולת להשוות לא רק לגרסה האחרונה, אלא לזהות תהליך שינוי מתמשך על פני רבעון או שנה. - סיכום מנהלים: הפלט צריך להיות שורה תחתונה ברורה למשקיע ("החברה ביצעה פיבוט לתחום ה-Health-Tech"), ולא רשימה טכנית של שינויי טקסט.

כלים

- שפות פיתוח: Python (מומלץ עבור Scraping ו-Data Science). - ספריות סריקה: Selenium, Scrapy, Puppeteer, Beautiful Soup. - מודלי שפה ובינה מלאכותית: OpenAI API (GPT-4o), Claude 3.5, LangChain, Hugging Face. - השוואת טקסט ועיבוד שפה: ספריות NLP (כגון NLTK או spaCy), אלגוריתמים לזיהוי דמיון טקסטואלי. - אחסון נתונים: מסד נתונים לשמירת היסטוריית הגרסאות (PostgreSQL, MongoDB) או Vector DB לשמירת Embeddings של תוכן האתר. - אינטגרציה: Slack API או Email API לשליחת ההתראות למשקיעים.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

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

רמזים

1. הפתרון המוצע מתבסס על ניצול מנגנון הבטיחות הקיים ברוב הכיריים המודרניים, המבוסס על חיישן טמפרטורה (תרמוקאפל / רגש חום). 2. התרמוקאפל מייצר זרם חשמלי חלש כאשר הוא חם (כאשר יש להבה), המחזיק שסתום גז סולנואידי פתוח. אם הלהבה נכבית, החיישן מתקרר, הזרם נפסק, והשסתום נסגר אוטומטית. 3. כיוון הפעולה הוא התערבות חשמלית במעגל זה. ניתן להשתמש בממסר (Relay) כדי לנתק את המעגל החשמלי של התרמוקאפל מהשסתום. ניתוק המעגל יגרום לשסתום הבטיחות להיסגר, ובכך יפסיק את זרימת הגז ויכבה את הלהבה. 4. יש לתכנן את המערכת כך שבמצב רגיל (לאחר כיבוי מתוזמן) הדלקה חוזרת של הכיריים תהיה פשוטה ולא תדרוש התערבות טכנית. 5. יש לשים דגש עליון על בטיחות. המערכת חייבת להיות 'Fail-Safe' – כל כשל במערכת התזמון צריך להוביל למצב הבטוח (כיבוי הגז).

כלים

* בקר: ארדואינו (Arduino) או ESP32 (עבור גודל קומפקטי וצריכת חשמל נמוכה) או ראזברי פאי (Raspberry Pi Pico/Zero). * ממסר (Relay): רכיב מפתח לביצוע הניתוק החשמלי של מעגל התרמוקאפל. * ממשק משתמש: מסך LCD (כגון 16x2) וכפתורים (Push Buttons) או מפסק סיבובי (Rotary Encoder) להגדרת הטיימר. * רכיבים פסיביים: נגדים, קבלים, חיווט מתאים. * מארז: רצוי לתכנן מארז בסיסי (אפשר בהדפסת תלת-ממד) עבור הבקר והרכיבים.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

עמותות וארגונים המגייסים תרומות שולחים לרוב דפי נחיתה גנריים לרשימות תפוצה רחבות. גישת "מידה אחת מתאימה לכולם" פוגעת אנושות באחוזי ההמרה ובמקסום ההכנסות משתי סיבות עיקריות: 1. חוסר רלוונטיות בתוכן: המסר השיווקי מתעלם ממניעי התורם (למשל, תורם המונע מנתונים מול תורם המונע מרגש). 2. אי-התאמה בסכומי התרומה (Ask String): דפי הנחיתה מציגים כפתורי תרומה עם סכומים קבועים (למשל: 50, 100, 200 ש"ח). קיבעון זה גורם לנזק כפול: הצגת סכום ברירת-מחדל נמוך מידי לתורם אמיד (High Net Worth) גורמת לאובדן הכנסה פוטנציאלית ("השארת כסף על השולחן"), בעוד שהצגת סכום התחלתי גבוה מידי לתורם בעל יכולת נמוכה יותר עלולה להרתיע אותו ולגרום לנטישת הדף ולביטול התרומה כליל. כיום חסרה טכנולוגיה שתדע להתאים דינמית את גובה הבקשה לפרופיל הכלכלי של התורם.

פיתרון

פיתוח מערכת המקבלת רשימת תפוצה (מיילים), ומייצרת באופן אוטומטי דף קמפיין ייחודי לכל נמען ("Hyper-Personalized Page"). המערכת תבצע תהליך העשרת דאטה (Data Enrichment) לאיסוף מידע פומבי על התורם, ותפעיל מנוע AI שיבצע שתי התאמות בזמן אמת: 1. התאמת תוכן ועיצוב: ג'ינרוט טקסט ותמונות (באמצעות כלי Generative UI כמו Lovable) המדברים בשפה ובתחומי העניין של התורם. 2. התאמת סרגל התרומה (Smart Ask Strategy): אלגוריתם שיעריך את היכולת הכלכלית של התורם (על בסיס טייטל, מקום עבודה, אזור מגורים וכו') ויעדכן את סכומי הכפתורים ב-Iframe הסליקה (למשל, Peach). כך, מנכ"ל בכיר יראה אפשרויות של 500/1000/5000 ש"ח, בעוד סטודנט יראה 18/36/72 ש"ח.

רמזים

1. הערכת יכולת כלכלית (Wealth Scoring): כיצד ניתן לגזור הערכה גסה של יכולת כלכלית מנתונים פומביים? (למשל: הצלבת Job Title מלינקדאין עם טבלאות שכר ממוצעות, או דירוג סוציו-אקונומי של אזור המגורים אם ידוע). 2. בניית ה-URL: כיצד להעביר את הפרמטרים (סכום התחלתי, שם, סגנון) בצורה מאובטחת ב-URL או באמצעות מזהה ייחודי (UUID) שמפעיל את ה-UI הדינמי בעת הטעינה. 3. פסיכולוגיה של תמחור: שימוש בטכניקות כמו "עוגן" (Anchoring) – כיצד הסכום האמצעי המוצג משפיע על הבחירה, וכיצד ה-AI יכול לבחור את העוגן האופטימלי לכל תורם. 4. אינטגרציה לסליקה: כיצד לשלוט דינמית בערכים המוצגים בתוך ה-Iframe של חברת הסליקה (Peach) באמצעות הזרקת קוד או שימוש ב-API שלהם.

כלים

1. Generative UI: Lovable, V0.dev, React. 2. Data Enrichment: Apollo.io API, Clearbit, Proxycurl (לחילוץ מידע מלינקדאין). 3. AI/LLM: OpenAI GPT-4o, Claude 3.5 Sonnet (לניתוח פרופיל וקביעת אסטרטגיית מחיר). 4. Payment Gateway: Peach Payments API / Documentation. 5. Backend: Python/Node.js (לניהול הלוגיקה והערכת ה-Scoring).

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

האתגר הוא יצירת מנגנון חכם המשלב איסוף מודיעין ממקורות פתוחים (OSINT), ניתוח רשתות חברתיות וזיהוי עקבות דיגיטליות. המטרה היא להפיק "מדד חשד ראשוני" (Initial Suspicion Score) לכל משתמש, רצוי בזמן אמת או בסמוך להצטרפותו. המערכת הנדרשת תדע: 1. לאסוף מידע ציבורי זמין על המשתמש (לדוגמה: שם משתמש, תמונת פרופיל, כתובת אימייל) ולמצוא הקשרים חיצוניים, בכפוף למגבלות חוקיות ואתיות. 2. לנתח דפוסי פעילות דיגיטליים, כגון תדירות פרסום, סוג השפה (למשל, שימוש בשפה גנרית או מועתקת), וההקשרים בהם הפרופיל פועל. 3. לזהות קשרים חריגים בין פרופילים שונים ברשתות ובקהילות (למשל, רשת בוטים). 4. לייצר מודל דירוג המעניק לכל משתמש ציון אמינות. פתרון זה יאפשר לפלטפורמות לקבל החלטות מושכלות, לייצר שכבת בקרה אוטומטית, ולשפר את איכות הקהילה.

רמזים

* מומלץ להתמקד בניתוח עקבות דיגיטליות ממקורות ציבוריים (כגון פורומים, רשתות חברתיות אחרות, מאגרי מידע) לצורך זיהוי דפוסים חריגים או אנומליות. * יש לבחון כיצד למפות קשרים ולהצליב מידע בין פלטפורמות שונות כדי לייצר תמונת אמינות ראשונית. * ניתן לבחון מאפייני רשת (Graph Theory) של פרופילים חשודים. לדוגמה, האם הפרופיל מחובר רק לפרופילים חדשים אחרים? האם הוא פועל ב"אי" מבודד? * מומלץ להשתמש בכלים לאיתור חריגות (Anomaly Detection) בשפה, בתדירות הפעילות, או באינטראקציות יוצאות דופן (למשל, שליחת הודעות זהות למשתמשים רבים). * כיצד המערכת תתמודד עם False Positives? יש לחשוב על מנגנון איזון שימנע סימון שגוי של משתמשים לגיטימיים.

כלים

המתמודדים רשאים לבחור באופן עצמאי את הכלים, אך מומלץ לשקול: * כלי OSINT לאיסוף מידע: Maltego, TheHarvester, או סקריפטים ייעודיים (למשל מבוססי Python עם ספריות כמו BeautifulSoup, Scrapy). * ניתוח נתונים ו-ML: Python (עם ספריות Pandas, Scikit-learn, TensorFlow/PyTorch) לטובת בניית מודל הדירוג וזיהוי אנומליות. * ניתוח רשתות (Graph): ספריות כמו NetworkX ב-Python, או בסיסי נתונים גרפיים כמו Neo4j. * ניתוח שפה טבעית (NLP): ספריות כמו spaCy או מודלי שפה (LLMs) לניתוח סנטימנט, זיהוי שפה גנרית, או איתור בוטים. * ממשקי API ציבוריים (בכפוף לתנאי שימוש): Twitter API, Reddit API, וכו'.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

שיעורי ההתמדה (Retention) בטיפול נפשי דיגיטלי בקרב ילדים ונוער נמוכים באופן קריטי, כאשר רק כ-30% עד 50% מהמשפחות ממשיכות בטיפול מעבר לשבועות הראשונים. הנשירה נובעת לרוב משילוב של עומס יומיומי, ירידה במוטיבציה, ממשק משתמש (UX) שאינו מותאם לקהל היעד, והיעדר חיזוקים חיוביים בין המפגשים. נשירה מוקדמת פוגעת ישירות ביעילות הטיפול ומונעת הטמעה של כלים רגשיים לאורך זמן. האתגר הוא לגשר על הפער הזה ולייצר מעורבות ארוכת טווח שתמנע נטישה בשלבים המוקדמים.

פיתרון

פיתוח אב-טיפוס למודול טכנולוגי המשתלב במערכות טיפול קיימות, שמטרתו להעלות את אחוזי ההתמדה ל-70% ומעלה. הפתרון צריך לכלול מנגנוני ניטור המזהים ירידה במעורבות בזמן אמת ומפעילים תגובה מותאמת אישית. המערכת תציע משימות קצרות וקלות לביצוע (Micro-missions), תשלב אלמנטים של משחוק (Gamification) המותאמים לגיל המטופל, ותאפשר להורים להיות מעורבים בצורה תומכת שאינה מייצרת עומס או התנגדות. אין צורך לפתח את הטיפול עצמו, אלא את מנגנון ה-Retention העוטף אותו.

רמזים

1. יצירת מנגנון "מיקרו-התערבות": פירוק משימות טיפוליות ליעדים יומיים קטנים ומתגמלים. 2. משחוק חכם: שימוש בשיטות כמו רצף הצלחות (Streaks), צבירת נקודות, מפות מסע ויזואליות או דמות מלווה (Avatar). 3. פרסונליזציה: התאמת סוג התגמול והקושי של המשימות למצב הרגשי הנוכחי של הילד ולגילו. 4. מעורבות הורית: כלי המאפשר להורה לתת "דחיפה קלה" (Nudge) לילד ללא יצירת קונפליקט. 5. לולאות משוב (Engagement Loops): יצירת ציפייה וסקרנות למפגש הבא או למשימה הבאה.

כלים

1. AI Models - לניתוח דפוסי נטישה והתאמת תוכן אישית. 2. Firebase / Supabase - לניהול משתמשים, דאטה בזמן אמת והתראות חכמות. 3. Figma - לעיצוב ממשק משתמש (UX/UI) המותאם ספציפית לילדים ונוער. 4. מחקרים בנושא Behavioral Design ו-Gamification בבריאות הנפש (MDPI, Pubmed). 5. פלטפורמות השראה: Joon, Mightier, Duolingo (למודל ההתמדה).

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

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

רמזים

1. השתמשו במודל הפיננסי הבסיסי הקיים ב-GitHub (לינק למטה) כנקודת מוצא לחישובי ה-DCF. 2. חשבו כיצד ניתן לזהות חריגות: אם חברה מדווחת על רווחיות הגבוהה ב-500 אחוז מהממוצע הענפי שנצבר בבסיס הנתונים שלכם, זהו דגל אדום. 3. שלבו יכולות NLP לסריקת שמות בעלי המניות בגוגל ובמאגרי מידע משפטיים כדי למצוא אזכורים שליליים. 4. ככל שהמערכת תצבור יותר דוחות (DATA), כך יכולת ההשוואה והזיהוי של דפוסים חריגים תשתפר – תכננו את מסד הנתונים בהתאם. 5. הציגו את רמת הסיכון בצורה ויזואלית וברורה למשתמש.

כלים

1. GitHub Base Model: https://github.com/Charlie-Hill/Financial-Models 2. Python (Pandas, NumPy) לחישובים פיננסיים. 3. ספריות NLP (כגון spaCy או BeautifulSoup) לניתוח טקסט וסריקת רשת. 4. מסדי נתונים (SQL/NoSQL) לשמירת היסטוריית דוחות להשוואה. 5. APIs פיננסיים (כגון Yahoo Finance) להשוואת נתוני שוק. 6. כלי ויזואליזציה (Streamlit/React) להצגת תזרים המזומנים ודירוג הסיכון.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

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

רמזים

* התמקדו במנגנון RAG איכותי שיודע לחלץ מידע מובנה מתוך מידע לא מובנה (כגון חילוץ שעות וימי פעילות מתוך טבלאות ב-PDF). * בנו תהליך "תחקור" (Slot Filling) חכם: אם המשתמש כותב "חוג ג'ודו", הסוכן צריך לדעת לשאול עצמאית "לאיזה גיל?" או "באיזה מתנ"ס?". * חשבו על חוויית משתמש (UX) פשוטה המזכירה התכתבות בוואטסאפ עם נציג אנושי. * נסו לשלב יכולות זיהוי דיבור (Speech-to-Text) להנגשה לאוכלוסיות מבוגרות. * המערכת צריכה לדעת להפנות לקישור המדויק ("Deep Link") לביצוע הפעולה.

כלים

* מודלי שפה: OpenAI API, Claude, HuggingFace Models. * אורקסטרציה וזיכרון: LangChain, LlamaIndex. * מסדי נתונים וקטוריים: Pinecone, ChromaDB, Weaviate. * עיבוד וסריקה: Python, BeautifulSoup, pdfplumber, PyPDF2. * פיתוח צד לקוח: React, Next.js, Vercel AI SDK, Tailwind CSS. * פיתוח צד שרת: Node.js, Express, FastAPI. * זיהוי דיבור: Web Speech API, OpenAI Whisper.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

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

רמזים

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

כלים

טכנולוגיות וכלים רלוונטיים: - Upstash Redis – בסיס נתונים מהיר לשמירת נתוני שימוש. - Cloudflare Workers / AWS Lambda – הרצת פונקציות מהירה ללא צורך בשרת. - היכרות עם תיעוד של API נפוצים ויכולת לשאוב מהם נתונים רלוונטיים.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

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

רמזים

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

כלים

- שימוש ב-API של מודלים שפתיים (LLM) מהחברות המובילות. - פתרונות לשימור הקשר הלוגי בין שלבי הקלט מבלי לחזור על מידע מיותר.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

פיתוח כלי המתממשק עם שירותי הענן (Google Workspace, Microsoft 365 וכו'), ומאפשר: - ניתוח נתוני שימוש של משתמשים - זיהוי משתמשים לא פעילים או לא מוכרים - השוואת המידע מול מסדי הנתונים של המוסד (כגון מערכת סטודנטים פנימית) - ניתוח הפסדים ועלויות נגררות - הפקת דו"חות ותובנות למנהלי המחשוב על משתמשים שדורשים הסרה או שינוי הרשאות

רמזים

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

כלים

- Google Workspace Admin SDK / Reports API - Microsoft Graph API - כלי כריית מידע (Data Mining) וניתוח סטטיסטי - חיבור למסדי נתונים של המוסד (MySQL, PostgreSQL או דומים) - כלים להפקת דו"חות והשוואות (כגון Google Sheets API או Power BI)

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

פיתוח רובוט אוטונומי נייד (על בסיס TurtleBot3 או דומה) המצויד במערכת ראייה ממוחשבת ותושבת פיזית (הניתנת להדפסה) לנשיאת מכשירי מדידה חיצוניים שונים. הרובוט יבצע סריקה ומיפוי (SLAM) של המרחב, תוך שמצלמה המותקנת עליו צופה בזמן אמת בצג של מכשיר המדידה. המערכת תכלול שלב כיול ראשוני בו המפעיל מניח את המכשיר, מסמן למצלמה את אזור הספרות (Region of Interest), ומגדיר את טווחי הנורמה (ערכים תקינים/ירוקים מול חריגים/אדומים). במהלך הנסיעה, הרובוט יפענח את הספרות מהמסך (OCR), יצליב אותן עם המיקום הנוכחי במפה, ויפיק בסוף התהליך מפת חום (Heatmap) המציגה את התפלגות המדדים במרחב, תוך התרעה על אזורים מסוכנים.

רמזים

1. כיול ממשק משתמש: חשבו על UI פשוט המאפשר למשתמש לסמן ריבוע סביב הספרות במסך המכשיר ולהגדיר סף עליון/תחתון להתראה. 2. עיבוד תמונה יציב: אתגר מרכזי הוא קריאת ספרות (OCR) ממסך דיגיטלי (LCD/7-Segment) תוך כדי תנועה ורעידות. כדאי לשקול אלגוריתמים לייצוב תמונה או סינון רעשים. 3. מודולריות פיזית: תכנון תושבת אוניברסלית או מתאמים שונים שניתן להדפיס בתלת-ממד כדי להחזיק פיזית מדי קרינה, גלאי גז או מדחומים שונים מול המצלמה. 4. מיפוי ונתונים: הסנכרון בין המיקום (x,y) לבין הערך הנמדד בזמן אמת הוא קריטי ליצירת מפה אמינה. 5. תנאי תאורה: המערכת צריכה להתמודד עם השתקפויות על מסך המכשיר או תנאי תאורה משתנים בחדר.

כלים

1. ROS (Robotic Operating System) - לניהול הרובוט והניווט. 2. OpenCV - לעיבוד תמונה, זיהוי האזור הרלוונטי במסך. 3. Tesseract או ספריות OCR דומות - לפענוח הספרות מהמסך. 4. SLAM Algorithms (כגון Gmapping או Cartographer) - למיפוי הסביבה. 5. Raspberry Pi 5 - מוח המערכת. 6. TurtleBot3 + LIDAR - פלטפורמת התנועה והחישה המרחבית. 7. מצלמת רשת (Web Camera) - לקריאת צג המכשיר. 8. כלי GUI (כגון Qt או ממשק Web) - להגדרת הכיול והטווחים.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

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

רמזים

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

כלים

- מודלים פיזיקליים דינמיים (Ballistics, CFD – זרמי אוויר, גזים) - Python עם ספריות: TensorFlow / PyTorch, XGBoost, NumPy, SciPy - GIS וכלי מיפוי: QGIS, Google Earth Engine - נתוני מזג אוויר: OpenWeatherMap API - נתוני יירוט/יירוטים היסטוריים (אם קיימים) - Blender / Unity – לסימולציות ויזואליות

זכויות יוצרים: החברה מעוניינת לשמור על כל זכויות היוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

אנליסטים של אבטחת מידע, חוקרי רשתות ואנשי SOC מתמודדים מדי יום עם כמויות עצומות של קובצי תעבורת רשת (PCAP - Packet Capture). קבצים אלו מכילים את התיעוד הגולמי של התקשורת (חבילות מידע, כתובות IP, פורטים, פרוטוקולים), אך הם קשים מאוד לקריאה ולהבנה אנושית מהירה. כדי להבין "מה קרה כאן", האנליסט נדרש לבצע עבודת נמלים של חיבור נקודות, סינון רעשים והבנת הקשרים מורכבים בין אירועים שנראים מבודדים. חסר כלי שמסוגל לגשר על הפער בין הנתונים הבינאריים היבשים לבין הסיפור האנושי של האירוע - מי דיבר עם מי, מתי, ומה הייתה המשמעות של אותה שיחה בהקשר הרחב.

פיתרון

פיתוח כלי קוד פתוח (Open Source) מבוסס בינה מלאכותית (AI/LLM), אשר קולט קובץ PCAP (קובץ הסנפה), מנתח אותו ומפיק ממנו "סיפור" נרטיבי וברור בשפה טבעית. המערכת לא רק תציג סטטיסטיקות, אלא תפרש את האירועים: היא תזהה את השחקנים הראשיים, תתאר את השתלשלות האירועים הכרונולוגית (למשל: "בשעה X החלה סריקת פורטים, ולאחריה נעשה ניסיון התחברות לשרת Y"), ותספק קונטקסט לאירועים חריגים. המטרה היא להפוך לוגים טכניים מסובכים לתיאור מצב קריא, המאפשר הבנה מיידית של תרחישים (כגון מתקפת סייבר, תקלת רשת או דליפת מידע) על ידי חיבור חכם בין פרטי מידע שונים.

רמזים

1. עיבוד מקדים (Preprocessing): מודלים של שפה (LLMs) מתקשים להתמודד עם קובצי PCAP גולמיים בגלל גודלם. מומלץ להמיר את התעבורה לסיכומי Sessions או Flows, לחלץ מטא-דאטה (Metadata) ורק אז להזין למודל. 2. העשרת נתונים: כדי שהסיפור יהיה עשיר, כדאי להצליב כתובות IP עם מידע גיאוגרפי (GeoIP), נתוני DNS, או מידע מודיעיני (Threat Intelligence) כדי להבין מי הם ה"דמויות" בסיפור. 3. זיהוי תבניות: נסו לאמן או להנחות את ה-AI לזהות דפוסי התנהגות מוכרים (כגון 3-way handshake שלא הושלם, העברת קבצים גדולה בפורט לא סטנדרטי) ולתרגם אותם למשפטים תיאוריים. 4. מבנה הסיפור: חשבו על יצירת ציר זמן נרטיבי - הקדמה (מצב נורמלי), האירוע המחולל (התקפה/תקלה), והתוצאה. 5. התמודדות עם הצפנה: חישבו כיצד המערכת תתייחס לתעבורה מוצפנת (TLS/SSL) – האם היא תנתח את ה-Handshake ואת נפח התעבורה כדי לשער מה קרה בשיחה?

כלים

1. Python - שפה ראשית לעיבוד הנתונים. 2. ספריות ניתוח רשת: Scapy, PyShark, Wireshark / TShark, Zeek (Bro). 3. מודלי שפה (LLMs): OpenAI API (GPT-4o/GPT-3.5), Claude, או מודלים מקומיים דרך HuggingFace / Ollama (כגון Llama 3) לשמירה על פרטיות המידע. 4. ספריות AI: LangChain, LlamaIndex לניהול הקונטקסט. 5. העשרה: VirusTotal API, GeoIP databases, WHOIS libraries.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

תוכנות וקבצים בינאריים (Binary Files) מכילים לעיתים קרובות חולשות אבטחה נסתרות, כגון שחיתות זיכרון (Memory Corruption), גלישות חוצץ (Buffer Overflows) ומצבי קצה לא מטופלים. חולשות אלו, המכונות לעיתים Zero-days (כשהן לא ידועות) או 1-days (לאחר פרסום), מהוות פתח לתוקפים להשתלטות על מערכות. איתור ידני של חולשות אלו בקוד מקומפל (Low-Level) הוא תהליך סיזיפי, איטי וכמעט בלתי אפשרי בקנה מידה רחב. האתגר הוא כיצד לבדוק באופן אוטומטי ומסיבי את עמידות הקובץ הבינארי בפני קלטים "רעילים" או בלתי צפויים, מבלי להכיר את קוד המקור שלו, כדי לחשוף נקודות תורפה לפני שהן מנוצלות לרעה.

פיתרון

פיתוח כלי Fuzzing (פאזר) אוטומטי וחכם. הכלי יקבל כקלט קובץ בינארי (Target) ויבצע עליו מתקפת "ריסוס" (Brute Force מתוחכם) של קלטים. המערכת צריכה לייצר באופן דינמי אלפי וריאציות של קלטים - החל מקלט אקראי לחלוטין ועד למוטציות על קלטים תקינים - ולהזריק אותם לתוכנת היעד. מטרת הכלי היא לנטר את ריצת התוכנה בזמן אמת, לזהות מתי היא קורסת (Crash) ולבודד את הקלט הספציפי שגרם לקריסה. הפתרון צריך לכלול מנגנון דיווח המנתח את סוג הקריסה (למשל, ניסיון כתיבה לכתובת זיכרון אסורה). כדי להוכיח את יעילות הכלי, יש להדגים את פעולתו על חולשות ידועות (1-days) ולוודא שהוא מצליח לשחזר את הקריסה.

רמזים

1. Mutation vs. Generation: החליטו האם הפאזר שלכם ייצור קלט מאפס (Generation) או ייקח קלט תקין ויבצע עליו שינויים קטנים (Bit flipping, גזירה והדבקה). 2. Coverage Analysis: כיצד תדעו אם הקלט שלכם הגיע לאזורי קוד חדשים? שקלו שימוש בטכניקות למדידת כיסוי קוד (Code Coverage) כדי לייעל את תהליך ה-Fuzzing. 3. Crash Monitoring: חשבו כיצד המערכת "תופסת" את הקריסה (שימוש ב-Signals בלינוקס למשל, או Debuggers). 4. ניהול משאבים: Fuzzing הוא תהליך אינטנסיבי. איך תנהלו את הזיכרון והמעבד כדי להריץ כמה שיותר בדיקות בשנייה? 5. רפרודוקציה: ודאו שהכלי יודע לשמור את הקלט המדויק שגרם לקריסה (PoC - Proof of Concept) לטובת חקירה עתידית.

כלים

1. שפות פיתוח: Python (ללוגיקה מהירה), C/C++ (לביצועים ואינטראקציה עם זיכרון). 2. ספריות וכלים לניתוח בינארי: LIEF, pwntools. 3. כלים להשראה או שילוב: AFL (American Fuzzy Lop), LibFuzzer, Honggfuzz. 4. סביבות ריצה ודיבאג: GDB, Linux Environment, QEMU (לאמולציה אם נדרש). 5. מאגרי חולשות לאימון: Exploit-DB (למציאת 1-days לבדיקה), CVE databases.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

ארגונים רבים מתמודדים עם הקושי לזהות תוקפים שכבר הצליחו לחדור לרשת הארגונית (Lateral Movement) או כאלו המבצעים סריקות מקדימות לאיסוף מודיעין. הדרך היעילה ביותר לזהות תוקפים אלו וללמוד על שיטות הפעולה שלהם היא באמצעות "מלכודות דבש" (Honeypots) – רכיבי רשת מדומים שנועדו לפתות את התוקף. עם זאת, הקמה, תחזוקה וניהול של מלכודות דבש אמינות דורשים משאבים רבים וידע טכני מעמיק. מנהלי אבטחה מתקשים לפרוס מלכודות מגוונות המותאמות לאיומים משתנים, ולעיתים קרובות המלכודות הקיימות סטטיות מדי וקלות לזיהוי על ידי תוקפים מנוסים, מה שמונע איסוף מודיעין איכותי על חולשות ושיטות תקיפה חדשות (Zero-day).

פיתרון

פיתוח פלטפורמה (SaaS או On-Premise) המאפשרת הקמה מהירה וקלה של רשת מלכודות דבש מגוונות. המערכת תאפשר למשתמש לבחור "פרופיל" למלכודת מתוך קטלוג (למשל: שרת בסיס נתונים פיננסי, פורטל משאבי אנוש, בקר IoT תעשייתי, או שרת פיתוח רגיש). בלחיצת כפתור, המערכת תרים את התשתית הנדרשת (קונטיינרים או מכונות וירטואליות), תגדיר את השירותים המתחזים, ותתחיל לנטר את התעבורה אליהם. המערכת תכלול רכיב ניתוח אשר יקליט את הפעולות שמבצע התוקף, יבודד את הקבצים או הפקודות הזדוניות שהוזרקו, ויפיק דוח מודיעיני על דפוס התקיפה, הכלים ששימשו את התוקף והחולשות שניסה לנצל.

רמזים

1. שימוש בקונטיינרים (Docker/Kubernetes): כדי לאפשר הרמה והורדה מהירה של שירותים, וכן כדי לבודד את התוקף בסביבה סגורה שלא תסכן את הרשת האמיתית. 2. התאמה אישית (Customization): המערכת צריכה לאפשר הגדרה של רמת האינטראקציה (Low-interaction מול High-interaction). האם המלכודת רק פותחת פורט או ממש מריצה מערכת הפעלה וגישה ל-Shell? 3. חיקוי אמין: המלכודת צריכה לייצר "רעש" של פעילות רגילה (Logs, Traffic) כדי להיראות אמינה ולא כשרת ריק ומחשיד. 4. ניתוח תעבורה (Sniffing): יכולת להקליט את התעבורה (PCAP) ולנתח פרוטוקולים נפוצים (SSH, HTTP, SQL) כדי להבין מה התוקף ניסה לעשות. 5. הטעיה דינמית: שינוי כתובות IP או מאפייני שרת באופן אוטומטי כדי להקשות על התוקף לזהות שמדובר במלכודת.

כלים

1. Docker / Kubernetes - לניהול והרצת המלכודות. 2. Python (Scapy, Socket libraries) - לכתיבת סקריפטים לחיקוי שירותים וניתוח תעבורה. 3. Wireshark / Tshark / Tcpdump - לניתוח חבילות מידע (Packets). 4. ELK Stack (Elasticsearch, Logstash, Kibana) או Splunk - לאגירה וניתוח של הלוגים וההתראות. 5. Cowrie / Dionaea - ספריות קוד פתוח למלכודות דבש שניתן ללמוד מהן או להתבסס עליהן. 6. Frontend Framework (React/Angular) - לבניית ממשק הניהול והדשבורד למשתמש.

זכויות יוצרים: לחברה אין צורך בזכויות יוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

פיתוח והרצת צ'אטבוט מבוסס בינה מלאכותית (LLM), המותאם אישית לתחום ידע מקצועי ספציפי, כרוכים כיום בעלויות גבוהות היוצרות חסם כניסה משמעותי. מצד אחד, שימוש בממשקי API של מודלים מסחריים מובילים גורר תשלום לפי היקף השימוש (Token usage), דבר שעלול להפוך לבלתי כלכלי ככל שהתעבורה גדלה. מצד שני, אימון והרצה מקומית של מודלים איכותיים דורשים שרתים עם כרטיסים גרפיים (GPU) חזקים ויקרים. מפתחים עצמאיים ועסקים קטנים נותרים ללא פתרון יציב המאפשר להם להציע שירותי AI מותאמים אישית במחיר נגיש.

פיתרון

פיתוח ארכיטקטורה או מערכת המאפשרת הנגשה של מודל שפה מותאם-תחום (Domain Specific) תוך הפחתה דרסטית של עלויות התפעול והחומרה. הפתרון צריך להתמקד ביעילות משאבים ולא רק בדיוק המודל. המערכת המוצעת יכולה להתבסס על שילוב יצירתי של טכנולוגיות: שימוש במודלים "רזים" ויעילים, דחיסת מודלים (Quantization) להרצה על חומרה עממית, או בניית מערכת ניתוב חכמה המפחיתה את הצורך בפניות לשרתים יקרים. היעד הוא הצגת יכולת טכנולוגית (POC) למערכת יציבה המספקת מענה איכותי בעלות שולית נמוכה.

רמזים

1. שימוש במודלים בקוד פתוח המותאמים לביצועים גבוהים במשקל נמוך (כגון משפחת Llama 3, Mistral, Gemma או Phi). 2. יישום טכניקות Fine-Tuning חסכוניות במשאבים (PEFT) כמו LoRA או QLoRA כדי להתאים את המודל למידע של Guardian Sphere מבלי לאמן את כל הרשת. 3. פיתוח מנגנון היברידי (Router): אלגוריתם שמסווג את מורכבות השאילתה ומחליט האם להשתמש במודל מקומי חינמי או להוציא קריאת API רק במקרים מורכבים. 4. הטמעת Semantic Caching: שמירת תשובות לשאילתות נפוצות כדי לחסוך עיבוד חוזר. 5. שימוש ב-RAG (Retrieval Augmented Generation) יעיל כדי לספק הקשר למודל קטן במקום להשתמש במודל ענק.

כלים

1. ספריות וכלי להרצת מודלים מקומיים: Ollama, Llama.cpp, vLLM, Hugging Face Transformers. 2. מסגרות עבודה (Frameworks) לפיתוח: LangChain, LlamaIndex. 3. טכנולוגיות אימון ודחיסה: BitsAndBytes, PEFT, AutoGPTQ. 4. מסדי נתונים וקטוריים למימוש RAG: ChromaDB, Faiss, Pinecone (גרסאות חינמיות/מקומיות). 5. שפות תכנות: Python (מומלץ ל-ML), JavaScript/TypeScript (לממשק).

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

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

רמזים

1. ניתוח סמנטי: השימוש ב-NLP (עיבוד שפה טבעית) כדי לזהות תשובות נכונות גם אם הניסוח שונה מהמקור שהזין המרצה (זיהוי נרדפות, הקשרים). 2. מדרג אמינות: המערכת יכולה לסמן תשובות שהיא "בטוחה" לגביהן בירוק, ותשובות הדורשות התערבות אנושית באדום. 3. למידת מכונה: המערכת יכולה "ללמוד" מדפוסי התיקון של המרצה ב-10 המבחנים הראשונים ולהחיל את התובנות על שאר המבחנים. 4. התמודדות עם כתב יד: במידה והמבחנים נסרקים, יש לשלב רכיבי OCR (זיהוי תווי דפוס/כתב יד) איכותיים. 5. מתן משוב אישי: יצירת בנק הערות אוטומטי בהתאם לטעויות נפוצות.

כלים

* שפות פיתוח: Python (מומלץ לעיבוד נתונים), JavaScript/React/Angular (לצד לקוח). * עיבוד שפה טבעית: ספריות כמו NLTK, SpaCy, Hugging Face Transformers. * מודלי שפה: שימוש ב-OpenAI API או מודלים מקומיים לניתוח טקסט (LLMs). * עיבוד תמונה (אם רלוונטי לסריקות): Tesseract OCR, Google Vision API, OpenCV. * מסדי נתונים: MongoDB או PostgreSQL לשמירת המבחנים והתוצאות.

זכויות יוצרים: החברה מעוניינת לשמור על כל זכויות היוצרים

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח תעו"נ כריית מידע מנהל עסקים חשבונאות

בעיה

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

פיתרון

פיתוח פתרון אבטחה היקפי (Add-on) המשתלב ברשת הקיימת ללא צורך בשינוי רכיבי הקצה. המערכת תדע לשבת בתווך או במקביל לתעבורה, לזהות מניפולציות על המידע, להצפין תעבורה גלויה, ואף "לתקן" או לחסום מידע זדוני לפני שהוא מגיע למערכות הבקרה. הפתרון יכול להתבסס על רכיב חומרה חיצוני או פתרון תוכנה המשמש כ-Secure Gateway, המבטיח את אמינות המידע (Integrity) ומונע הטעיה של מערכות הניהול במפעל.

רמזים

1. שימוש בפרוקסי (Reverse Proxy) שמקבל את המידע מהחיישן הלא-מאובטח, מצפין אותו, ומעביר אותו לשרת. 2. ניטור פסיבי של התעבורה (Sniffing) וזיהוי אנומליות בפרוטוקול התקשורת או בערכים המתקבלים (למשל, קפיצות לא הגיוניות בערכים). 3. שימוש ברכיבי קצה זולים (ESP32 / Raspberry Pi) שישמשו כ"שומר סף" פיזי המתחבר לחיישן המקורי. 4. חתימה דיגיטלית על חבילות מידע (Packets) כדי לוודא מקוריות. 5. התמודדות עם פרוטוקולים תעשייתיים נפוצים (Modbus, MQTT, HTTP) שאינם מאובטחים במקור.

כלים

1. חומרה: Raspberry Pi, ESP32, Arduino. 2. תקשורת ופרוטוקולים: Wireshark, MQTT, HTTP/S, TCP/IP, Modbus. 3. שפות וספריות: Python (Scapy, Socket), C++, NodeJS. 4. כלי אבטחה ורשת: Nginx, HAProxy, OpenSSL.

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

רלוונטי בעיקר למחלקות: תוכנה ומדמ"ח אלקטרוניקה אלקטרו-אופטיקה תעו"נ כריית מידע מנהל עסקים חשבונאות

שותפים

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


ניתן ליצור קשר גם במייל yazamut@jct.ac.il
© כל הזכויות שמורות לשרייבר לב-טק | מרכז היזמות של המרכז האקדמי לב 2026 | תנאי שימוש | הצהרת נגישות | מפת אתר
WhatsApp Icon