לעדן

חזרה למסמך הראשי

סמי, ה־managers ו־AI Flows

נכתב בידי עוזר AI שעובד עם יוסף, מתוך תיעוד העבודה במרכז, כרקע לפגישה ב־20.10.

היום AI Flows הוא המקום שבו מגדירים במרכז תהליך קליני שמבוסס על מודל שפה כקונפיגורציה ולא כקוד: קובץ YAML של צמתים, פרומפטים בקובצי Markdown, ושאילתה שמורה ברוזטה. את התהליך מפרסמים כ־endpoint שמערכות אחרות קוראות לו. ממנו יוצאים היום המכתבים האישיים בפנימיות דרך SmartER, ובו נבנים מכתבי השחרור, ה־pre-physician, הרדיולוגיה ומכתבי הקרדיולוגיה. המערכת לא נולדה כמערכת. היא סוף של שושלת בת שנתיים: מסכם פגישות, סיכום קליני בשם סמי, ה־managers, ה־linker, הפלייגראונד, ובסוף ה־POC של אלון אגמון שהפך למאגר ולמוצר. הצוות עצמו הציג לצוות פוטון ב־7.10 את השושלת כ־SDK, אחר כך AI-Suite, ואחר כך AI Flows. העמוד הזה מספר את הקו לפי הסדר, עם התאריכים והאנשים שהניעו כל שלב, אחר כך מסביר איך המערכת עובדת היום, ובסוף מונה את מה שפתוח.

שורשים: מסכם פגישות, סיכום קליני וסמי (2024–2025)

הקו מתחיל לפני שהיה במרכז מוצר קליני. ב־18.7.2024, ביום הראשון שבו יוסף בן יהודה הגיע לבניין, הוא ישב בישיבת ARC, וראה שאת הסיכום השבועי של הישיבה כותבים ביד. למחרת בבוקר הוא שלח סיכום אוטומטי של הישיבה, בגרסה ארוכה ובגרסה קצרה. בתוך חודשיים "המתמלל והמסכם" כבר היה שירות פנימי שעמיתים ביקשו בשם, ובסוף אוגוסט 2024 יוסף עבד על מערכת סיכומים מבוססת DSPy. באותה תקופה, בספטמבר 2024, גל גושן מההנהלה תיאר רעיון של פלטפורמה ששרשרת קריאות למודלים. אז לא נבנה ממנו דבר, אבל זו בדיעבד אותה שאלה ש־AI Flows עונה עליה היום.

בית החולים רצה סיכום גם בקנה מידה קליני. הרעיון עלה בספטמבר 2024 ושוב בנובמבר, ובפועל נפתח ב־19.3.2025, כשהמרכז פתח ביום אחד שלושה מסלולים קליניים מבוססי מודלי שפה: סיכום, אמביינט ושיחה. רחל ויטיס, מנהלת הדאטה סיינס, כתבה את התוכנית ופתחה את קבוצת העבודה ב־30.4.2025. בשישה השבועות הראשונים יוסף היה המהנדס היחיד במסלול. הוא שלף את נתוני המחלקה מקמיליון, ובנה preprocessing, backend, הערכות וממשק. ב־6.5 הצינור עבד מקצה לקצה, עדיין באופן נאיבי, וב־14.5 אפשר היה לטעון מטופלים ולקבל עליהם סיכום. ב־15.5 נערכה הפגישה הראשונה עם הרופאים על הפלט, וב־28.5 הוצג דמו לפרופ׳ קרייס. מ־8.6 שי גנכיל הצטרף ומצא בעיית latency גדולה, ומשם יוסף עבר מבנייה לבד לאינטגרציה ולסקירה.

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

המחלקה הראשונה הייתה קרדיולוגיה. ב־23.6.2025 יערה כץ, מנהלת הפיתוח, החליטה להעלות את המערכת כמו שהיא, בידיעה שחלק מהעבודה ייזרק אחרי refactor, כי היה חשוב שהרופאים יתחילו לתת משוב. ב־3.7 הוצג הכלי לכל הצוות, בסוף יולי הוא קיבל את השם סמי, וב־27.7 חובר ממשק חדש בעברית. ב־10.8.2025 סמי עלה לפרודקשן, ולמחרת נפתח פיילוט במרכז הלב, עם חמישה סוגי מקרים ממופים. זה היה המוצר הקליני הראשון של המרכז שהגיע לרופאים אמיתיים. ב־1.9 דווחו בצוות תגובות של שני קלינאים: לפי אחת מהן מדובר בשינוי מהותי בעבודה, ולפי דיווח הצוות הכלי חסך 30–40 דקות במכתב של אשפוז ארוך. ב־16.10.2025 הנהלת הקרדיולוגיה אישרה את התוכנית, וב־20.11 עברו בפיילוט 200 מכתבים. אלה מספרים שנמדדו בתוך הצוות ולא באופן בלתי תלוי.

הפיילוט חשף גם את המחיר של הבנייה המהירה. ב־21.8.2025 התגלה שנתונים נשמרו ב־Mongo ברגע יצירת המטופל ולא התרעננו, ומכאן התחיל מעקב באגים מסודר. ב־25.8 גיא דולינסקי פרסם רשימה ממוספרת של תקלות, ורחל פרסמה מפת אחריות כתובה. ההפניות לרשומה היו נכונות רק בכ־70–80% מהמקרים, ופרומפט אחד ניסה לסווג, לייצר ולבסס הכול בבת אחת. בסוף אוגוסט מאמץ תחום בזמן של יומיים פיצל את עבודת הסוכן היחיד, והוספת הנתונים החסרים פתרה את רוב ההזיות. התיקונים האלה הם מה שהוליד את המערכות הבאות. הפרומפטים והתוכן הקליני בסמי היו של קבוצת הדאטה סיינס ושל אנשי המוצר; הצינור שמסביב היה של הפיתוח.

סמי לא בוטל אלא הוחלף בהדרגה. בינואר 2026 נוספו לו נתוני מיון וביקורים ונוספה פנימית ג׳, במרץ עלה ענף שליפות גדול, ובמאי הודגמו המלצות קרדיולוגיות כפלט שני לצד המכתב. ביוני 2026 חדר הצוות כבר תיאר את מה שנשאר כחבילה ולא כאפליקציה. מה שעבר הלאה הוא היכולת: מכתבי השחרור והמכתבים למטופל נבנים היום כ־flows. המעבר של מכתבי הקרדיולוגיה עצמם תלוי בציון הערכה, והדאטה סיינס החליטו לא להחליף פרומפט כשהציון ירד.

ה־managers ו־In the Loop (2025–2026)

מתוך התיקונים בסמי נולדו ה־managers. כל manager הוא רכיב שמקבל את נתוני המטופל ומפיק תוצר קליני אחד, כמו מכתב שחרור, סיכום לפני רופא או סיכום בדיקות עזר; זו יחידה שמחזיקה משימה קלינית אחת: הוא שולף את מה שהוא צריך, קורא למחולל אחד או יותר, ומחזיר תוצאה מובנית. השם התחיל ב־14.5.2025 כ־pumaManager, לקוח שאפשר להחליף לו את היעד במשתנה סביבה; מאור שגיא מהדאטה סיינס ציינה באותו יום שיש לה manager דומה משלה. ביוני 2025 גיא צייר את הרכיב הגנרי לכל משימה ומסך אחד שמנהל את כולם, מה שנקרא אז Bluebox, ומזה ההפשטה ירשה את צורת הפריסה.

הדיון שהוליד את ההפשטה היה על השאלה למי היחידה מיועדת. רחל רצתה כלי סיכום גנרי אחד. יוסף טען ב־3.6.2025 שכל משימה צריכה flow קצת שונה בתוך תבנית אחידה. אלון, סגן נשיא המו״פ, הביא מבחוץ את רעיון הפאנל של סוכנים שלכל אחד תפקיד אחר. וב־1.7.2025 יערה הגדירה שהמטרה היא יחידת קונפיגורציה שהדאטה סיינס יוכלו להפעיל. ב־25.8.2025 יוסף פתח ענף להפשטות, וב־28.8 אפשר היה להגדיר manager מעל מחוללים משותפים בלי לשנות את התשתית הקיימת. הכלל שסוכם אז הוא שכל עוד הקלט והפלט קבועים, ל־manager לא משנה מה קורה בתוך המחולל. בינואר 2026 הניסוח כבר היה חזק יותר: manager הוא קונפיגורציה, פרומפט ו־JSON schema, ולכן שינוי במה שמנהל ה־OCR מחלץ הוא שינוי קונפיגורציה ולא קוד.

ה־manager הראשון מעל ההפשטה, באותה הודעה מ־28.8.2025, היה In the Loop: המכתב למטופל, כי מכתב שחרור שנכתב לרופאים לא קריא למטופל. הקונספט הוצג לפרופ׳ קרייס כבר ב־6.8.2025, שלושה שבועות לפני שורת קוד ראשונה. ב־3.2.2026 שי כתב את manager In the Loop, ויערה הגדירה את המוצר כניסוי בחלוקת העבודה בין הפיתוח לדאטה סיינס. ב־6.3 הממשק דיבר עם ה־manager לראשונה. ב־15.6.2026 המכתב הנגיש הראשון הגיע למטופל; המוצר זיכה את שני ירדני כמי שבלעדיה המוצר לא היה קיים, ואת נועה ורסנו כמי שישבה עם הרופאים כדי להתאים את המכתב. ב־23.6 נשלח בפנימית ה׳ המכתב הראשון ישירות בידי הרופאה, ושמונה מכתבים יצאו מהמחלקה באותו יום. טהר אברג׳ל ויאיר גינת זוכו על חיבור האינטגרציות.

במשך שנה ה־managers היו הדרך שבה המרכז שלח AI קליני: ה־pre-physician, סיכום הבדיקות, מכתבי השחרור והקבלה, ה־OCR של הפניה סרוקה ו־In the Loop. בדרך התנהל דיון ארוך על מקומם: מחוץ ל־AI SDK בספטמבר 2025, כי הם מחזיקים לוגיקה שאינה AI; ישיבת ארכיטקטורה בנובמבר שכותרתה הייתה איפה ה־managers יישבו; וחזרה לתוך ה־SDK בדצמבר. מהתקלות של אותה תקופה יצאו רוב כללי העבודה שהמרכז עובד לפיהם היום. ב־17.12.2025 שינוי גרם ל־15–20 קריאות ל־managers לכל מטופל במיון, וכ־38 אלף קריאות בלילה אחד. ב־1–2.1.2026 כל ה־managers נפלו בפרודקשן בגלל שינוי בקובץ קונפיגורציה, ויוסף איתר את המקור. מזה נקבעו הכללים: כל העלאת גרסה ל־manager נכנסת לשלושת קובצי ה־values יחד (8.1), עובדים ב־merge requests ולא בדחיפות ישירות, כל שינוי ממשק מקבל אישור מוצר (סוף ינואר), וכל קלט ופלט של manager נכתבים ללוג בזוגות (מ־5.1). ב־23.3.2026 ה־managers עלו כמערכת פרודקשן יציבה, ה־OCR עבד והמידע זרם, ולמחרת הממשק החדש יכול היה לקרוא להם כדי לייצר מכתבי שחרור, מכתבים באנגלית ומכתבים אישיים.

ה־linker, הפלייגראונד וההחלטה לבנות (נובמבר 2025–יוני 2026)

הבעיה שנשארה הייתה שאי אפשר לכתוב manager בלי מפתח. הוספה או שינוי של משימה קלינית דרשו שינוי קוד, בניית Docker, העלאת גרסה בשלושה קובצי values ופריסה. בתחילת 2026 היו שלושה מסלולי קריאה שונים ל־managers. ב־4.2.2026 יוסף כתב את ה־linker: כל manager רושם את עצמו בדקורטור, ה־linker נותן לו endpoints, הוספת manager עולה שורה אחת ב־Dockerfile, ו־endpoint אחד קורא ל־manager ולגארדריילס יחד, במקום ש־TMR יתזמר אותם. ב־7.2 יוסף כתב לקבוצה את הנימוק למנוע סוכנים, כדי לתת הקשר לסלע ענבר ולעמית מהדבאופס. סגירת ה־linker הייתה העדיפות הראשונה של יערה, והוא מוזג ב־19.2 באישור רחל. ב־21.2 הוצג עובד דרך TMR עם טרייס מקצה לקצה. זו אותה ארכיטקטורה של AI Flows בקטן: יחידה שנרשמת ומקבלת endpoint.

במקביל התפתח קו שני, הפלייגראונד, והמילה עצמה כיסתה כמה דברים. הפלייגראונד הראשון נבנה בלילה אחד ב־16.11.2025, כדי שהמוצר יוכל להציג את סמי במחלקות אחרות עם פרומפט מותאם לכל מחלקה; צוות המוצר הודיע עליו בקבוצת ההודעות של המרכז. ארבעה חודשים אחר כך המוצר עדיין השתמש בו הרבה, ולכן ב־4.3.2026 יערה קבעה שצריך לבנות פלייגראונד מעל רוזטה, ושמה את Playground 2.0 בסדר העדיפויות של הצוות. במאי הוחלט למקם אותו בתוך AI-Suite, וב־4.6 יוסף בנה גרסה ראשונה: שאילתת רוזטה, קונפיגורציה חיה של manager, תצוגת נתונים, וכפתור שפותח merge request עם הקונפיגורציה החדשה. ב־26.6 יצאה גרסה עובדת של משטח השאילתות מעל רוזטה, שבו בוחרים מטופל, מחלקה וסל נתונים בכמה לחיצות ומקבלים מזהה שאילתה; גיא ויערה קבעו באותו לילה שהשם שלו הוא הסטודיו, ולא הפלייגראונד, כדי לשמור על שפה משותפת. ההבחנה הזו נשארה: הסטודיו מגדיר נתונים, הפלייגראונד מגדיר flows.

באותה תקופה המרכז בחן גם את הדרך המוכנה. בין 12 ל־24 במרץ 2026 רץ מסלול off-the-shelf: סלע בנה ב־Langflow סוכן ששולח מייל, כל רכיבי Langflow הופעלו ברשת הסגורה, ועומר מצא את שרת ה־MCP שלו. ב־14.3 יוסף המליץ לא ללכת על Langflow לשכבת הסוכנים, מסיבות טכניות: קשה לעבוד בו עם קוד, הוא בנוי לפייפליינים סטטיים יחסית ולא ללולאה סוכנית, ומנוע כמו אליס לא היה רץ עליו. גיא טען שצורת בלוק הקוד שבו יכולה להתאים. בצד הפיתוח השתמשו באותה תקופה ב־agno. בפועל זו הייתה ההחלטה לבנות ולא לאמץ, לפחות לשלב הזה.

מה־POC של אלון לפרודקשן (יוני–ספטמבר 2026)

את AI Flows כפי שהוא היום הגה אלון. ב־30.6.2026 אלון לקח את הובלת הדיזיין של הבקאנד הרב־סוכני ושל הפלייגראונד, וכתב POC; את הרעיון לקח משיחה עם צוות שמריץ בקאנד של מאות סוכנים. מה־POC הזה באים שני הדברים שעליהם המערכת בנויה: פורמט ה־YAML של ה־flow וה־launcher שמריץ אותו. באותו יום גיא אמר בחדר ההנדסה של SmartER שה־managers עוד לא שולפים מרוזטה, ושהוא מעדיף לחכות לפלייגראונד המלא מאשר לייעל את TMR לפני כן. לכן זה היה החסם של כל המסלול.

ב־11–12.7.2026 יוסף וגיא הפכו את ה־POC למאגר. לפי דיווח של גיא לאלון בקבוצת ההנדסה של רוזטה ב־12.7, הם לא נגעו ב־launcher, רק הזיזו אותו לתיקיית flow, מיפו לו את תיקיית הקונפיגורציות מגיט, והוסיפו מעליו בקאנד ופרונטאנד של פלייגראונד, כך ששמירה של flow פותחת merge request עם קובץ YAML בפורמט של אלון. אלון השיב שהעדפתו היא ספרייה מתוחזקת, כל עוד היא עומדת בדרישות. באותו שרשור הונחה החלטת הדיזיין לגבי גארדריילס: ה־manager עצמו מחזיר משפטים מבוססים, כלומר משפט ורשימת הפניות לכל משפט, וצומת גארדרייל שנותן ציון להפניות הוא אופציונלי מעל זה. גיא לקח את עדכון ה־CI/CD והעביר את התוצאה לאילן בואניש לבדיקה.

ב־21.7 AI Flow עלה לבטא עם בדיקות, ויערה ביקשה מיוסף להעביר עליו את טהר, רפאל אשורוב ועומר. ב־26.7 גיא הגדיר את השלב הבא: לחבר את שלושת המשטחים, כולל שאילתות דינמיות ב־TMR ויצירת מכתבים. ב־29.7 המערכת חשפה את כל הסוכנים שהוגדרו, אפשרה לפרסם כל אחד מהם בפורמט מוסכם מול TMR, חשפה את ה־endpoints ב־Swagger, והפרסום פתח merge request. באותו לילה חובר אליה הסטודיו של רוזטה, כך ששאילתה שנשמרת ברוזטה זמינה ב־flow לפי ה־query id שלה. ב־2.8 client חסר ב־Keycloak שבר את הפלייגראונד, וסלע תיקן אותו.

ב־9.8 גיא קבע ש־AI Flow הוא הדבר העיקרי שצריך לסדר, בתיאום עם הדאטה סיינס, כי רוב המשתמשים לא אמורים להגיע לרוזטה בכלל. ב־11.8 נערכה ישיבת ההעברה: המנוע והממשק עברו לשי, וה־flows עצמם לאילן, ה־Lead NLP של הדאטה סיינס. ההעברה הייתה ישיבה ולא מסמך. ב־13.8 יערה ביקשה מאילן לרכז את כל השינויים בענף אחד, וקבעה שאף flow נוסף לא מומר לפני שאחד עובד מקצה לקצה; באותו יום שי בנה את In the Loop כ־flow דרך הפלייגראונד, הסוכן הראשון שנבנה שם, ואילן אישר שהוא נראה טוב. ב־19.8 שי העלה לבטא את ממשק ה־flows, והפלייגראונד היה שמיש לראשונה. גיא קבע באותו יום שמכתבי AI Flow עולים לבטא לצד המכתבים הקיימים ולא מחליפים אותם בשלב הזה, והורה לשפר את חוויית המשתמש. רחל ואילן כינסו את הדיון על שאלות הדיזיין הפתוחות, ויערה מנתה אותן: מיקום הגארדרייל, צומת המכתב וה־OCR.

ב־23.8.2026 AI Flows עלה לפרודקשן, וטהר הודיע על כך. ב־24.8 אילן פתח merge request שהעביר לבטא את כל הסוכנים של In the Loop. ב־30.8 גיא הקפיא שינויים שוברים ברוזטה עד שהמכתב הראשון יעבור לפרודקשן דרך AI Flows. ב־31.8 עבר המכתב הראשון של In the Loop מקצה לקצה לתוך המוצר, ורחל חילקה את הקרדיט: אילן הכניס את ה־flow, שני ועומר עבדו על הדאטה, ושי וטהר חיברו אותו ל־TMR. ב־1.9 flow מלא של מכתב מטופל לפנימית היה בבטא, עם משפטי פתיחה וסגירה מהפרומפט והפניות שנפתרות מול רוזטה. ב־3.9 שי טען בחדר ההנדסה שכדאי להאיץ את המעבר, כי המסלול הישן נכשל במקומות ש־AI Flows מצליח בהם. ב־9.9 המכתבים האישיים בפנימיות בפרודקשן כבר הגיעו מ־AI Flows, ובאותו שרשור נאמר שגם manager ה־OCR יעבור לחיות שם. בספרינטים 25–33 נגעו ב־flows כ־43 משימות בלוח, ובספרינט 32 נסגרו שני באגי הפרודקשן הגדולים: איטיות של מכתבי השחרור ושיעור כשל גבוה.

ספטמבר היה חודש התלות ברוזטה. ב־10.9 AI Flows נכשל מול רוזטה על timeouts של בסיס הנתונים, והסיבה נמצאה בשליפת הביקורים שהצטרפה גם ל־QFlow ול־MetaVision; היא הוכנסה מאחורי דגל. ב־15.9 גיא כתב את שרשרת התלות: TMR בפרודקשן קורא ל־AI Flows בפרודקשן, שקורא לרוזטה בבטא, כי רוזטה בפרודקשן עוד לא תמכה בעריכת שאילתות. ב־16.9 אומת ש־SmartER בפרודקשן מדבר עם AI Flows ו־Wildfire בפרודקשן, והמכתבים נוצרים בהצלחה. ב־17.9 טהר העביר את משתני הסביבה מקובץ env לקונפיגורציה מסודרת ב־pydantic, פרסם קובץ דוגמה לכל המשתמשים, ושחרר את התיקון שאפשר לאילן לסיים את ממשק הגארדריילס. מאז טהר מחזיק את התפעול של AI Flows ושל הפלייגראונד מול מי שמריץ אותם. ב־7.10 שינוי בחוזה של ממשק הרצת השאילתה בין רוזטה בטא ל־AI Flows הגיע לפרודקשן, ו־AI Flows בפרודקשן החזיר שגיאת 422. החוזה הישן הוחזר בתוך כ־40 דקות ונכתב תחקיר. המקרה מראה את נקודת התורפה המבנית של המערכת: שינוי חוזה ברוזטה יכול לשבור flow בפרודקשן בלי שאף בדיקה תתריע.

איך זה עובד היום

כל flow הוא קובץ YAML בגיט, עם פרומפטים בקובצי Markdown לידו. כל צומת מגדיר מודל וטמפרטורה משלו, ומשתנים אפשר להצהיר בתוך ה־YAML או להעביר כקלט. צמתים שלא תלויים זה בזה רצים במקביל, ואפשר לשלב שלבים עוקבים עם שלבים מקביליים. צומת הדאטה לא מכיל שאילתה. הוא מפנה לשאילתה שמורה ברוזטה לפי query id, ורוזטה מחזירה את הנתונים מהרשומה דרך GraphQL. כשמדביקים את אותו מזהה ב־Wildfire מקבלים את השאילתה המדויקת ואת ה־SQL שמאחוריה. בספטמבר הפיתוח והדאטה סיינס הגיעו יחד למסקנה שמספיקים שלושה סוגי צמתים: צומת שמריץ קוד, צומת שמריץ מודל, וצומת סופי שמוציא מכתב. הצומת הסופי, ה־LetterNode, מחזיר את החוזה ש־SmartER מצפה לו. מהר התברר שצריך גם צומת תנאי, למשל: אין הפניה, אז לא מריצים OCR. הצומת קיים ועובד ב־YAML, והבנייה שלו בממשק עדיין בעבודה.

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

מתחת לפני השטח רץ מפרש שנכתב במרכז. הוא לוקח את ה־YAML, מפרק ומרכיב אותו, והצורה הסופית היא גרף של LangGraph, אבל רוב הקוד עוסק בהמרה עצמה. הבסיס הוא הקוד של ה־POC, והוא השתנה הרבה מאז. למי שנכנס לקוד זה חשוב, כי מי שמחפש התנהגות סטנדרטית של LangGraph לא תמיד ימצא אותה. ב־2.9 אלון הגדיר דרישה אחת מהמנוע: להישאר בשימוש סטנדרטי בספרייה.

הפרסום עובד דרך merge request. שמירה בפלייגראונד או פרסום פותחים MR עם ה־YAML; פרסום מעדכן את ה־endpoint הקיים במקום לייצר חדש, וה־flows נשמרים כ־revisions. בחלק מה־flows רצה בזמן הפרסום הערכה מול מכתבי זהב, אבל האישור ידני ואין CI ל־flows. הצרכן העיקרי הוא TMR, שקורא ל־flow כשמשהו משתנה בתיק ומציג את המכתב בתוך SmartER. ה־Wizard של SmartER אמור לאפשר לשייך מכתבים מ־flows למחלקה בלי מפתח. אפשר גם לקרוא ל־AI Flows מבחוץ דרך API, עם client credentials שמבקשים מהדבאופס; בקשה כזו הגיעה כבר ב־6.9 מצד הדאטה סיינס.

חלוקת העבודה, כפי שהוצגה לצוות פוטון ב־7.10: אנשי המוצר כותבים את הפרומפטים לפי אפיון, הדאטה סיינס כותבים גארדריילס ומודולים ומחזיקים את ה־flows, ושי מחזיק את המנוע והממשק, עם גיא ויוסף בדיזיין ובסיוע. באותה הצגה יוסף ציין שחלק גדול ממה שהוצג הוא עבודתו של אילן. הפלייגראונד הוא המקום שבו כולם נפגשים: מגדירים flow, מריצים אותו על מטופל אחד מול שאילתה של רוזטה, רואים את הנתונים, את הפלט ואת ההפניות, ודוחפים את הקונפיגורציה כ־MR. ב־14.10 שי פתח לאילן PR עם כלי בדיקה: צומת Data Input שמקבל JSON או GraphQL עם משתנים, עצירה של test באמצע, הצגת קלט ופלט לכל צומת ב־debug גם בהצלחה וגם בכשל, ומעקב אחרי ריצות API מתוך הממשק. הכלים נסקרו ב־15.10.

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

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

מה קורה עכשיו ומה פתוח (אוקטובר 2026)

שלושה דברים בתנועה. הראשון: ב־18.10 שי פתח refactor גדול בעקבות סקירת קוד של יוסף. הוא מסדר את הקוד לפי הקונבנציות של הצוות ומעביר לשכבת common פונקציות ומודלים שהיו משוכפלים, בלי לשנות פיצ׳רים. בלוח הכרטיס משויך לשי וליוסף, ממתין לסקירה, בספרינט 34. השני: כלי הבדיקה שתוארו למעלה. השלישי: העברת הרדיולוגיה ל־flows. בנוסף נפתחו באוקטובר באגים מוכרים: פרסום שמגיע ל־conflict, ריצות ובדיקות שאינן קשורות ל־revision מסוים, flow שלא נפתח ל־revision ותוקן ב־15.10, וקריסה כש־YAML אינו תקין.

אלה הבעיות הפתוחות לפי התיעוד, מהפחות להכי הרבה הכרעה.

להערכת הסוכן, הסדר הנכון מתחיל בבדיקות חוזה בין רוזטה ל־AI Flows, כי שם המערכת נשברה בספטמבר ובאוקטובר, ובבדיקות רגרסיה ל־flows המרכזיים, כך ש־refactor כמו זה של שי אפשר יהיה למזג על סמך בדיקות שמראות שההתנהגות לא השתנתה ולא רק על סמך קריאה של מאות שינויים. אחרי זה, גבול עלות לפני ריצה ולא רק דיווח אחריה. בכיוון הזה ב־7.10 יוסף העלה מול אילן רעיון: לתת ל־flow לבקש נתונים דרך tool calling, במקום לדחוף למודל את כל ה־JSON של המטופל. המלצת הסוכן היא להכריע במקביל בשתי שאלות ארגוניות, בעלים לפלייגראונד והחלטה מסודרת בשאלת לבנות או לקנות, כי בלי הכרעה בהן כל שיפור במנוע הוא שכבה נוספת על קוד שאולי יוחלף.

חזרה לתשובות

המרכז והדרך · רוזטה ו־Wildfire · SmartER ו־TMR · הסטודיו · הפלטפורמה · מה קורה עכשיו