שילוב Dialogflow NLP בצ'אטבוט למובייל

שילוב מנוע NLP (Dialogflow) בצ'אטבוט נייד

לעתים קרובות אנו רואים פרויקטים שבהם שילוב Dialogflow מתחיל ללא הבנה ברורה של ההבדלים בין ES ל-CX. לקוחות בוחרים ב-ES בשל פשטותו, אך כעבור שישה חודשים מתמודדים עם הצורך לשכתב את כל לוגיקת ה-intents—ארכיטקטורת State Machine ב-CX אינה תואמת ל-Flow הליניארי של ES. המשימה שלנו היא לעזור לכם לבחור את הגרסה הנכונה ולהגדיר את השילוב כך שהבוט יעבוד ביציבות מהגרסה הראשונה. עם ניסיון של למעלה מ-5 שנים בפיתוח נייד, אנו מבטיחים איכות בכל שלב.

מדוע בחירת גרסת Dialogflow היא קריטית

Dialogflow CX ו-Dialogflow ES הם מוצרים שונים מהותית. ES משתמש ב-flow ליניארי: intents מעובדים ברצף, contexts חיים למספר מוגבל של תורות. CX בנוי על State Machine: כל שלב הוא עמוד עם מעברים מפורשים. מעבר מ-ES ל-CX דורש עיצוב מחדש מלא של הסוכן. CX מתאים יותר לתרחישים מורכבים רב-שלביים (הזמנת מוצרים, תמיכה טכנית), בעוד ES מתאים לשאלות ותשובות פשוטות. הבחירה תלויה בתרחישים שלכם; אנו מציעים ביקורת לפני תחילת הפיתוח.

כיצד להגדיר אימות ללא סיכוני אבטחה

התיעוד הרשמי של Google Cloud מציע להשתמש בקובץ service account JSON ישירות באפליקציה. זה לא מקובל—המפתח הפרטי מגיע ל-APK/IPA. הגישה הנכונה: האפליקציה הניידת שולחת טקסט לשרת הקצה שלכם, והשרת מתקשר עם Dialogflow באמצעות ספריית google-cloud-dialogflow עם ה-service account. אנו מיישמים שרת proxy ב-Node.js או Python שמעבד בקשות ומחזיר תשובות. דוגמה ב-Node.js:

const { SessionsClient } = require('@google-cloud/dialogflow-cx');
const client = new SessionsClient();
async function detectIntent(projectId, location, agentId, sessionId, text, languageCode) {
  const sessionPath = client.projectLocationAgentSessionPath(
    projectId,
    location,
    agentId,
    sessionId
  );
  const request = {
    session: sessionPath,
    queryInput: {
      text: {
        text,
      },
      languageCode,
    },
  };
  const [response] = await client.detectIntent(request);
  return response.queryResult;
}

כיצד לפתור בעיות רב-לשוניות והקשר

Dialogflow תומך במספר שפות על סוכן אחד, אך יש להוסיף ביטויי אימון לכל שפה בנפרד. אם תעבירו const { SessionsClient } = require('@google-cloud/dialogflow-cx'); const client = new SessionsClient(); async function detectIntent(projectId, location, agentId, sessionId, text, languageCode) { const sessionPath = client.projectLocationAgentSessionPath( projectId, location, agentId, sessionId ); const request = { session: sessionPath, queryInput: { text: { text }, languageCode, }, }; const [response] = await client.detectIntent(request); return response.queryResult; } לסוכן ללא ביטויים ברוסית, Dialogflow יחזיר fallback intent עם ביטחון נמוך—המשתמש לא יבין את התשובה. אנו מגדירים ערכות שפות ובודקים אותן באמצעות הסימולטור.

ניהול הקשר הוא מקור נפוץ לשגיאות. ב-ES, contexts חיים למספר תורות לאחר הגדרתם. אם לא מאפסים את ההקשר לאחר סיום תרחיש, המשתמש עלול לקבל תשובה בלתי צפויה. ב-CX, בעיה זו נפתרת באמצעות מעברים מפורשים בין עמודים. המהנדסים שלנו מתכננים flows כך שכל תרחיש מסתיים באיפוס הקשר לכל הדיאלוגים הפעילים.

יישום בצד הנייד

באנדרואיד, אנו משתמשים ב-OkHttp או Retrofit כדי לקרוא לשרת ה-proxy. מזהה Session נוצר פעם אחת בתחילת הסשן ונשמר בזיכרון—לא ב-SharedPreferences, סשנים לא אמורים לשרוד הפעלות מחדש של האפליקציה.

class DialogflowRepository(private val api: ChatApiService) {
    private val sessionId = UUID.randomUUID().toString()

    suspend fun sendMessage(text: String, locale: String): ChatResponse {
        return api.detectIntent(
            DetectIntentRequest(
                sessionId = sessionId,
                text = text,
                languageCode = locale
            )
        )
    }
}

ב-iOS—באופן דומה באמצעות URLSession או Alamofire. אין קריאות ישירות ל-Google API מהלקוח. לעיבוד תגובות עשירות (כרטיסים, כפתורים, קרוסלות), אנו מנתחים languageCode: ru ומרנדרים את רכיבי התצוגה המתאימים: class DialogflowRepository(private val api: ChatApiService) { private val sessionId = UUID.randomUUID().toString() suspend fun sendMessage(text: String, locale: String): ChatResponse { return api.detectIntent( DetectIntentRequest( sessionId = sessionId, text = text, languageCode = locale ) ) } } , fulfillmentMessages, TextBubbleCell.

עיצוב סוכן: המלצות מעשיות

עבור בוט production, נדרש:

• קיבוץ intents לפי תחום (הזמנות, תמיכה, שאלות נפוצות) וקיבוץ שלהם
• הגדרת fallback intent עם מספר גרסאות תשובה (לפחות 5)
• הוספת Small Talk כ-flow נפרד—אחרת הבוט מתעלם בגסות מהערות לא פורמליות
• מימוש Webhook לתשובות דינמיות (סטטוס הזמנה, רמות מלאי)
• ביטויי אימון: לפחות 10–15 גרסאות לכל intent, אחרת הביטחון יהיה נמוך בדיבור טבעי. אנו משתמשים ביצירת מילים נרדפות אוטומטית כדי להגדיל כיסוי.

השוואה בין Dialogflow ES ו-CX

CX עולה על ES בתרחישים רב-שלביים לפחות פי 2 במהירות הפיתוח וביציבות. חיסכון בתקציב על שכתוב—עד 50% עם בחירה נכונה מההתחלה.

מה כוללת העבודה שלנו

• ביקורת תרחישים קיימים ואיסוף דרישות
• בחירת גרסת Dialogflow (ES או CX) עם נימוקים
• עיצוב סוכן: intents, ישויות, contexts, flows/עמודים
• פיתוח שרת proxy (Node.js/Python) עם אימות
• שילוב SDK באפליקציה הניידת (Android Kotlin, iOS Swift)
• הגדרת מימוש Webhook עם ה-CRM/מסד הנתונים שלכם
• בדיקות באמצעות סימולטור Dialogflow ועל מכשירים אמיתיים
• תיעוד תחזוקה (גישה, סקריפטים, קונפיגורציות)
• הדרכת צוות בניהול סוכן

איך אנחנו עובדים: שלבים

1. אנליטיקה — פירוק תרחישים, איסוף דוגמאות דיאלוג, זיהוי מקרי קצה.
2. עיצוב — בניית מפות דיאלוג וקבלת אישור הלקוח.
3. יישום — יצירת הסוכן, כתיבת ה-proxy, שילוב בלקוח.
4. הדרכה ובדיקות — לפחות 50 דיאלוגי בדיקה לכל שפה.
5. השקה — פרסום ל-App Store / Google Play, הגדרת ניטור.

הערכות זמנים

• שילוב עם סוכן קיים: מ-3 עד 4 ימים (כולל הגדרת proxy ולקוח).
• פיתוח סוכן מאפס עבור 5–10 תרחישים בתוספת לקוח נייד: מ-1.5 עד 2 שבועות.
• תמיכה לאחר השקה: לפי בקשה, עם אחריות לחודש לתיקון תקלות שהתגלו.

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