פיתוח תוסף AI ל-WordPress במפתח-על: מ-REST API ועד ווידג'ט צ'אט

למה תוסף AI של WordPress נשבר בעומס אמיתי

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

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

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

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

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

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

מה משתנה באתר WordPress אחרי ההטמעה

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

זמן עד לקטע הראשון של התשובה

התשובה נמסרת בזרימה: הווידג'ט מציג את המילים הראשונות בזמן שהמודל משלים את השאר, לכן ההמתנה עד לטקסט הנראה הראשון יורדת מ-4–9 שניות ל-0.5–1.5. התשובה המלאה מגיעה תוך 2–4 שניות — עבור המבקר זה ההבדל בין ממשק «חי» לתחושה של עמוד תקוע.

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

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

יציבות תחת עומס

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

סוג הכשלים שנעלם לחלוטין

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

שלוש גישות לחיבור המודל: טבלת השוואה

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

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

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

סדר העבודה: מביקורת האתר ועד מסירת הקוד

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

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

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

הרכב המסירה: קונפיגורציות, סכמות ותקנונים

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

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

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

מקרה בוחן: עוזר צ'אט בקטלוג של 40 אלף פריטים

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

מה שינו

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

מדדים לפני ואחרי

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

מה לעשות אם באתר כבר מותקן ווידג'ט צ'אט מוכן?

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

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

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

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

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

שאלות טכניות נפוצות לפני תחילת העבודה

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

מה יקרה בעדכון גדול של האתר?

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

האם הווידג'ט יעמוד בקפיצת תנועה?

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

אפשר לעשות השקה מדורגת?

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

מה כלול בתמיכה לאחר המסירה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

מה תקבלו בתשובה:

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

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