יישומי בינה מלאכותית ללא קוד וסוכני RAG: פיתוח בפלטפורמת Dify

למה הטמעת Dify נעצרת בשלב האב-טיפוס

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

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

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

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

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

אפקטים מדידים בעת העברת סוכנים למסלול הייצור

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

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

גישות להטמעת Dify: השוואה בין שלושה מודי עבודה

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

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

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

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

שלבי העבודה ההנדסית: מביקורת ועד מסירת המסלול

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

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

מה מוסרים אחרי ההשקה: קונפיגורציות, תפקידים, נהלים

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

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

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

מקרה בוחן: איך צמצמנו טיפול ידני בפניות

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

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

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

מה השתנה

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

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

מה לעשות אם אב-טיפוס של הסוכן כבר נבנה ידנית?

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

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

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

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

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

מגבלות הפלטפורמה וספקות טכניים נפוצים

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

היכן הנתונים שלנו נשמרים?

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

עד כמה נהיה תלויים בכם?

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

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

נדבר על המשימה: מה לשלוח ומה להבהיר

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

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

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