איך אנחנו בונים סוכני AI: הפייפליין, המודולים והמתודולוגיה שלנו

Ronnie Projects · אוטומציה חכמה ופיתוח AI

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

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

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

מה זה בכלל סוכן AI?

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

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

בפועל זה אומר:

סוכן חשבוניות ספקים שמקבל PDF-ים מהמייל, מחלץ שורות פריטים, מצליב אותן מול הזמנות פתוחות ב-ERP (מערכת ניהול עסקי מרכזית — כמו Priority או SAP — שמנהלת מלאי, הזמנות, חשבונות ועוד), מדגיל חריגות מחיר ומעביר חשבוניות תואמות לאישור תשלום — בלי שאדם פותח קובץ אחד.
סוכן שירות לקוחות שקורא בקשת החזרה, מאתר את ההזמנה המקורית, בודק את מדיניות ההחזרות מול תאריך הרכישה, מנסח פתרון ומטפל בפנייה אוטונומית או מעביר לנציג עם כל ההקשר מוכן — מקצץ זמן טיפול ממוצע מ-12 דקות לפחות מ-90 שניות.
סוכן מודיעין תחרותי שמנטר עשרות מקורות מידע לפי לו"ז, מחלץ סיגנלים מובנים (שינויי מחיר, השקות מוצר, תנועות מלאי) ומעביר בריפינג מסודר לצוות כל בוקר — במקום שעות של מחקר ידני.
סוכן מכירות שמאזין לפעילות ב-CRM (מערכת לניהול קשרי לקוחות — כמו Salesforce או HubSpot — שמרכזת את כל המידע על לקוחות, עסקאות ותקשורת), מזהה עסקאות שהתקררו לפי דפוסי התנהגות, מנסח הודעות פולו-אפ מותאמות אישית לאישור הצוות, ומתעד כל פעולה בחזרה ל-CRM אוטומטית.
סוכן דיווח פנימי שמושך נתונים ממערכות מנותקות, מיישב אי-התאמות, בונה סיכומים מובנים ומייצר דוחות מוכנים להנהלה על פי דרישה — בלי אנליסט שמחבר גיליונות אקסל ידנית.

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

הפייפליין שלנו לבניית סוכני AI

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

שלב 1: גילוי ועיצוב הסוכן

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

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

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

הפלט של השלב הזה הוא מפרט סוכן פורמלי: מטרת הסוכן, חוזה הקלט/פלט שלו (מה הסוכן מקבל ומה הוא אמור להחזיר), הכלים שהוא יכול להשתמש בהם, וכללי ה-Escalation (הסלמה — מתי הסוכן מעביר את הטיפול לאדם במקום להחליט לבד) שהוא חייב לפעול לפיהם.

שלב 2: ארכיטקטורת נתונים וידע

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

זה כולל:

חיבור למערכות הקיימות שלכם — ERP, CRM, מסדי נתונים, אחסון מסמכים
עיבוד נתונים לא מובנים — ניקוי, חלוקה לצ'אנקים (Chunks — קטעים קטנים של מידע שקל לחפש בהם) ואינדוקס (Indexing — יצירת "תוכן עניינים" שמאפשר חיפוש מהיר) של מסמכים, PDF-ים, מיילים וטבלאות
בניית שכבת ה-Retrieval (שליפה — המנגנון שמוצא מידע רלוונטי לפי שאלה) — כדי שהסוכן יוכל לשאוב ידע רלוונטי בזמן ריצה במקום להמציא מידע מהזיכרון
חילוץ מובנה ומיפוי סכמות — שימוש ב-LLM (מודל שפה גדול — כמו ChatGPT, Claude, Gemini; בעצם ה"מוח" של הסוכן שמבין שפה ומסוגל לנתח טקסט) לחילוץ נתונים מאומתים ממקורות לא מובנים (חשבוניות, חוזים, טפסים) ומיפוים לסכמות (Schemas — תבניות נתונים מסודרות, כמו טבלה עם שדות קבועים) שמערכות הדאון-סטרים (Downstream — מערכות שמקבלות את הפלט ועושות בו שימוש בשלב הבא) מצפות להן. זה מחליף פארסרים (Parsers — תוכנות שמנתחות טקסט לפי כללים נוקשים וקורסות כשמשהו לא מדויק) שבירים עם מודלים שמבינים הקשר ומתמודדים עם וריאציות בגמישות.
חלוקה סמנטית לצ'אנקים — במקום לחתוך מסמכים לפי מספר תווים קבוע, אנחנו חותכים לפי משמעות (Semantic — לפי תוכן, לא לפי גודל טכני). סעיף תמחור נשאר שלם. פסקת אחריות לא נחתכת באמצע. זה משפר דרמטית את איכות השליפה.
תיוג מטה-דאטה וסינון — כל קטע בבסיס הידע מועשר במטה-דאטה (Metadata — מידע על המידע: מתי נכתב, מאיזה מקור, איזה סוג מסמך). בזמן שליפה הסוכן יכול לסנן לפי מטה-דאטה לפני חיפוש — מהיר יותר, זול יותר, מדויק יותר.
ולידציה של נתונים — סוכנים שמטפלים בנתונים עסקיים חייבים לוולידייט (Validate — לאמת ולוודא תקינות) את הפלט לפני שהם פועלים. אנחנו בונים שכבות ולידציה שבודקות ערכים מחולצים מול פורמטים ידועים, טבלאות רפרנס וחוקים עסקיים (למשל: האם סכום החשבונית תואם לסכום שורותיה? האם התאריך בתוך חלון חוזה תקף?).
הזרקת הקשר פרדיקטיבית — עבור סוכנים שרצים על תהליכים חוזרים, אנחנו מבצעים Pre-fetch (טעינה מקדימה של מידע שסביר שיידרש) ומאחסנים בקאש (Cache — זיכרון ביניים שמחזיק מידע שכבר נשלף, כדי לא לטעון אותו שוב) הקשר על בסיס דפוסים מהיסטוריית השימוש. זה מקטין לייטנסי (Latency — זמן ההמתנה עד שהסוכן מגיב) ומונע קריאות שליפה מיותרות.
בניית גרף ידע — עבור תחומים מורכבים עם ישויות רבות ומקושרות (מוצרים, ספקים, חוזים, לקוחות), אנחנו בונים גרפי ידע (Knowledge Graph — מבנה שמייצג קשרים בין ישויות, כמו "ספק X קשור למוצר Y שקשור לחוזה Z") שמאפשרים לסוכן לעבור על קשרים ולא רק למצוא טקסט. זה חזק במיוחד לסוכנים שמבצעים בדיקות קומפליינס (Compliance — עמידה בדרישות רגולטוריות או חוזיות) או ניתוח על ריבוי ישויות.
יצירת נתונים סינתטיים לטסטים — לפני שסוכן נוגע בנתוני פרודקשן, אנחנו מייצרים דאטאסטים סינתטיים (Synthetic Data — נתונים מלאכותיים שנוצרו על ידי מחשב, אבל נראים כמו נתונים אמיתיים) שמשקפים את המאפיינים הסטטיסטיים של הנתונים האמיתיים. זה מאפשר לנו לבדוק מקרי קצה (Edge Cases — מצבים נדירים או קיצוניים שבהם המערכת עשויה להתנהג בצורה לא צפויה) ומצבי כשל בבטחה.

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

שלב 3: פיתוח הסוכן

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

בחירת LLM וראוטינג — בחירת המודל (מוח ה-AI) הנכון למשימה, ובמערכות רבות שימוש בראוטר (Router — מנגנון שמחליט אוטומטית לאיזה מודל לשלוח כל שאילתה) שבוחר דינמית בין מודלים לפי סוג השאילתה, מורכבות ועלות. מודל קליל וזול מטפל בסיווג פשוט; מודל חזק יותר מטפל בניתוח מורכב.
ארכיטקטורת פרומפט ועיצוב מערכת — זה יותר הנדסה מכתיבה. פרומפט (Prompt — ההוראה שנותנים למודל ה-AI כדי לכוון את התנהגותו) מגדיר את זהות הסוכן, יכולותיו, אילוציו ופורמט הפלט שלו. אנחנו מנהלים גרסאות של פרומפטים בדיוק כמו שאנחנו מנהלים גרסאות של קוד.
Chain-of-Thought וסקפולדינג ריזונינג — Chain-of-Thought (שרשרת מחשבה — טכניקה שבה מנחים את ה-AI לחשוב בקול רם שלב אחר שלב לפני שהוא מגיע למסקנה) ו-Scaffolding (פיגומים לחשיבה — מסגרת שמפרקת בעיה מורכבת לצעדים קטנים). זה מקטין שגיאות דרמטית במשימות מרובות שלבים. טכניקות כמו ReAct (ראזן + אקט — הסוכן מנמק ואז פועל לסירוגין) ו-Tree-of-Thought (עץ מחשבות — הסוכן בוחן מספר נתיבי חשיבה במקביל ובוחר את הטוב ביותר) מיושמות כשהבעיה מצדיקה זאת.
חיבור כלים ו-Function Calling — Function Calling (קריאת פונקציות — יכולת של ה-AI לבקש מהמערכת לבצע פעולה חיצונית, כמו חיפוש במסד נתונים או שליחת מייל) מחבר את הסוכן ליכולות חיצוניות (ראו מודול 3 למטה).
ארכיטקטורת זיכרון — תכנון שכבת הזיכרון קצרת וארוכת הטווח (ראו מודול 2 למטה).
פרסונה לסוכן וגאררדריילס התנהגותיים — Guardrails (גדרות בטיחות — חוקים שמונעים מהסוכן לחרוג מגבולות מוגדרים, כמו לא לאשר החזר כספי מעל סכום מסוים ללא אישור אנושי). זה קריטי לסוכנים מול לקוחות, שם טון ואמינות משפיעים ישירות על מוניטין המותג.
לולאות ביקורת עצמית ורפלקציה — סוכנים מתקדמים לא רק מייצרים פלט — הם מעריכים אותו. אנחנו מיישמים דפוסי רפלקציה שבהם הסוכן מבקר את הטיוטה שלו מול קריטריונים לפני שהוא מחזיר אותה. זה תופס פלטים נמוכי-איכות לפני שהם מגיעים למשתמש.
אכיפת פלט מובנה — שימוש ב-Constrained Decoding (פענוח מוגבל — אילוץ ה-AI להחזיר תשובה בפורמט קבוע מראש ולא טקסט חופשי) או Output Parsers (מנתחי פלט — כלים שהופכים את תשובת ה-AI לנתונים מסודרים) כדי להבטיח שהסוכן מחזיר נתונים בפורמט קריא-למכונה כמו JSON (פורמט נתונים מסודר שמערכות תוכנה יכולות לקרוא בקלות) שמערכות אחרות יכולות לעבד בצורה אמינה.
אופטימיזציית עלות ולייטנסי — סוכני פרודקשן רצים בסקייל (Scale — בהיקפים גדולים, על אלפי פעולות ביום). אנחנו מפרפרים (מייעלים) כל שלב, מיישמים אסטרטגיות קאשינג לשאילתות חוזרות, דוחסים חלונות קונטקסט (Context Windows — כמות הטקסט שה-AI יכול "לזכור" בשיחה אחת; גדול יותר = יקר יותר) בחוכמה ובוחרים רמות מודל לפי מורכבות המשימה — כדי לשמור על עלויות תפעול צפויות.
שכבת אורקסטרציה — Orchestration (תיאום — ניהול מרכזי שמחליט מי עושה מה ומתי) למערכות מרובות-סוכנים. אנחנו בונים את לוגיקת הקואורדינציה שמנתבת משימות, מנהלת סטייט (State — מצב שוטף: מה כבר קרה, מה עוד בתהליך) בין סוכנים, מטפלת בכשלים ומבטיחה שזרימת העבודה הכוללת מגיעה למטרתה גם כשצעדים בודדים נכשלים (ראו מודול 4 למטה).

שלב 4: טסטינג ו-Red Teaming

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

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

שלב 5: פריסה ומוניטורינג

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

המודולים המרכזיים שלנו

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

1. RAG — Retrieval-Augmented Generation

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

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

איך אנחנו מיישמים:

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

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

2. זיכרון וניהול קונטקסט

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

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

איך אנחנו מיישמים:

אנחנו משתמשים בארכיטקטורת זיכרון שכבתית:

זיכרון עבודה (Working Memory) — חלון הקונטקסט הפעיל לאינטראקציה הנוכחית. אנחנו מנהלים את זה בזהירות, כי למודלים יש מגבלות על כמות הטקסט שהם יכולים "לזכור" בבת אחת ומילוי שלהם בהיסטוריה לא רלוונטית פוגע בביצועים.
זיכרון אפיזודי (Episodic Memory) — לוג של שיחות עבר שניתן לשלוף כשרלוונטי. אם משתמש אומר "כמו הפעם הקודמת", הסוכן יכול לחפש ולמצוא.
זיכרון ישויות (Entity Memory) — עובדות קבועות על ישויות ספציפיות (לקוחות, הזמנות, מוצרים) מאוחסנות בנפרד ומוזרקות לשיחה כשאותה ישות מופיעה.
זיכרון סמנטי (Semantic Memory) — ידע ארוך-טווח המאוחסן בשכבת ה-RAG (ראו לעיל).

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

3. שימוש בכלים ו-Function Calling

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

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

איך אנחנו מיישמים:

מודלי AI מודרניים (Claude, Gemini, GPT-4) תומכים ב-Function Calling מובנה — הם יכולים לזהות מתי כלי צריך להיות בשימוש ולייצר קריאה בפורמט תקין. אנחנו:

מגדירים ערכת כלים לכל סוכן לפי התפקיד שלו
מיישמים Handlers (מטפלים — קוד שמתרגם את בקשת ה-AI לפעולה אמיתית) לכלים עם טיפול שגיאות ו-Fallbacks (תגובות גיבוי כשמשהו נכשל)
בונים בקרות גישה לכלים כדי שסוכנים יוכלו לעשות רק את מה שהם מורשים
מלגים (מתעדים) את כל קריאות הכלים ל-Auditability (יכולת ביקורת — מעקב מלא אחרי מה שהסוכן עשה ומתי)

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

4. אורקסטרציה מרובת-סוכנים

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

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

איך אנחנו מיישמים:

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

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

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

5. Human-in-the-Loop — אדם בלולאה

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

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

איך אנחנו מיישמים:

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

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

6. אינטגרציות מערכת (ERP, CRM ומעבר לכך)

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

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

איך אנחנו מיישמים:

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

אינטגרציית ERP — Priority, SAP ואחרים. סוכנים יכולים לשאול מלאי, לוולידייט הזמנות, למשוך נתוני ספקים ולעדכן רשומות בזמן אמת.
אינטגרציית CRM — סוכנים יכולים לחפש היסטוריית לקוח, ליצור טיקטים, לעדכן שלבי דיל ולהפעיל רצפי פולו-אפ.
פלטפורמות איקומרס — Shopify ופלטפורמות מותאמות אישית. סוכנים יכולים לעבד הזמנות, לבדוק סטטוס פולפילמנט (Fulfillment — תהליך הכנת ומשלוח ההזמנה) ולטפל בלוגיקת החזרות.
מערכות מסמכים — קליטת PDF-ים, מיילים ומסמכים סרוקים כקלטים חיים לפייפליין הסוכן.
Webhooks וטריגרים Event-Driven — Webhooks הם הודעות אוטומטיות שמערכת אחת שולחת לאחרת כשקורה משהו (למשל: "נכנסה הזמנה חדשה"). Event-Driven (מונע-אירועים) — ארכיטקטורה שבה הסוכן מופעל בתגובה לאירוע ולא לפי לוח זמנים קבוע.

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

הסטאק שאנחנו בונים עליו

אנחנו אגנוסטיים למודלים (Model Agnostic — לא קשורים לספק אחד; בוחרים את הכלי הנכון לכל עבודה), מה שאומר שאנחנו בוחרים את ה-LLM הנכון לכל עבודה במקום ברירת מחדל לספק אחד.

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

Gemini (Google) מצטיין במשימות מולטימודליות (Multimodal — מסוגל לעבד סוגי מידע שונים: טקסט, תמונות, קול) ואינטגרציה הדוקה עם סביבות Google Workspace. כשלקוחות רצים על תשתית Google, Gemini הוא התאמה טבעית.

מודלים קוד-פתוח (Open Source) — LLaMA ואחרים הם הבחירה שלנו כשפרטיות הנתונים היא Non-Negotiable (לא ניתנת להתפשרות). לעסקים בתעשיות מוסדרות או לאלה שמטפלים בנתונים פנימיים רגישים, פריסת מודל קוד-פתוח בהוסטינג מקומי (On-Premises — המערכת רצה על שרתים של הלקוח ולא בענן חיצוני) אומר שהנתונים לא יוצאים מהסביבה שלכם.

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

מה הופך את הגישה שלנו לשונה

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

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

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

אנחנו מתכננים לפרודקשן מהיום הראשון. לוגינג, מוניטורינג, טיפול Fallback (תוכנית גיבוי כשמשהו נכשל), נקודות HITL, טסטינג רגרסיה (Regression Testing — בדיקה שעדכונים חדשים לא שברו דברים שעבדו קודם) — אלה לא אפטרת'טס (Afterthoughts — דברים שחושבים עליהם בדיעבד). הם בנויים לתוך הארכיטקטורה.

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

למי זה מיועד

אנחנו בונים סוכני AI לעסקים שיש להם:

תהליכים חוזרים ובנפח גבוה שדורשים כרגע שיפוט אנושי בכל שלב
מערכות ארגוניות פעילות (ERP, CRM) ורוצים ש-AI יעבוד עם המערכות האלה, לא יחליף אותן
ניסיון עם כלי אוטומציה מדף (Off-the-shelf — פתרונות מוכנים לשימוש שאינם מותאמים אישית) שהגיעו לגבול שלהם
צורך בשותף שיכול לקחת אחריות על כל הסטאק — מארכיטקטורת הנתונים ועד פריסה ותמיכה שוטפת

אם זה נשמע כמו המצב שלכם — כדאי שנדבר.

מוכנים לגלות מה אפשרי?

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

ללא התחייבות. פשוט שיחה מעשית.

בואו נדבר ←