יש לך בעיה באתר וורדפרס? העזר בבינה המלאכותית לדבג אותו

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

באופן עקרוני, לא צריך הכוונה מיוחדת לפתוח איזה ChatGPT זה או אחר (מהנקודה הזו והלאה אני כותב LLM) כדי לבקש עזרה בנוגע לאתר לא פועל. הבעיה היא שוורדפרס ידוע לשמצה בתופעת ה-WSOD שלו – מסך המוות הלבן. אתם מקבלים טלפון מלקוח שהאתר לא עובד, נכנסים ואללי – המסך לבן לגמרי ולך תדע מה לעשות. שאלות כלליות מ-LLM יקחו הרבה זמן ועלולות להביא אותי לנקודות פחות טובות והזיות. בהרצאה ובפוסט הזה אני כותב על דברים שעבדו לי ויכולים מאד לעזור.

להאכיל את ה-LLM

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

יש לנו כמה לוגים עיקריים:

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

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

לוג השגיאות יהיה תחת debug.log ב-wp-content. רפרשו כמה פעמים את הדף ותעתיקו את הקובץ משם.

הלוג השני הוא לוג ה-PHP שמציג שגיאות PHP כלליות, אפשר לגשת אליו מפאנל הניהול (אם קיים) או לגשת אליו דרך ה-SSH. המיקום של ה-error log תלוי בסוג המכונה שיש לכם. גם הלוג הזה חשוב לפענוח תקלות וצרות.

לוג שלישי הוא לוג שגיאות השרת עצמו. לפעמים ה-PHP בסדר גמור, אבל יש בעיות בשרת (כמו בעיות מקום למשל!). במקרה הזה, הלוג של WordPress לא יראה לכם כלום וצריכים את הלוג של Apache, Nginx או כל שרת אחר שיש לכם. במקרה הזה – אם יש לכם פאנל ניהול אפשר להוריד אותו משם או להכנס עם SSH ולגשת אליו משם. הם נמצאים בד״כ ב-/var/log/apache2/ או ב-/var/log/nginx/. אבל זה תלוי מערכת.

ולבסוף – לוג השגיאות של MySQL. יש לנו שני לוגים. הלוג הראשון הוא לוג שגיאות כללי שהמיקום שלו משתנה לפי ההגדרה ב-my.cnf תחת log-error. למשל:log-error=/var/log/mysqld.log. הלוג השני הוא Slow Query Log.

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

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

לשאול את ה-LLM

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

Attached are the Apache log and the WordPress log. I have White Screen of Death issue, can you give me analysis based on those logs?

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

הזיות וכשלונות

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

אם הגעתם לשלב שבו ה-LLM מקבל את הלוגים ומציע פתרון שנראה מורכב, יש דרך טובה ואובייקטיבית יחסית להבין אם הוא צודק – להשתמש בגישת LLM as a judge. פתחו LLM אחר (למשל קלוד), ספקו לו את הלוגים ואת הפתרון שה-LLM הראשון נתן ותשאלו אותו אם הפתרון סביר בציון של מ-1 עד 10. זה יתן לכם כיוון אם הפתרון סביר או לא.

אבטחה

יש מקרים מתועדים שבהם ה-LLM מציע פתרונות שמחייבים התקנות של תוספים. הבעיה היא שהתוספים האלו עלולים להיות מומצאים (ראו את המחקר הזה להרחבה או חפשו LLM package hallucination). מה שקורה הוא ש-LLM לפעמים הוזה מודל או תוסף ואז תוקפים אמיתיים יוצרים מודל כזה שתואם להזיות ושמים בו תוכן זדוני. התקפות של מודולים שנוצרו בהזיות התקיימו כבר. שימו לב היטב לפתרונות שה-LLM מציע והפעילו שיקול דעת.

לסיכום

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