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

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

שאלה דומה אינה תמיד שאלה מקבילה

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

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

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

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

מתעדים באיזו סביבה התקבלה התשובה

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

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

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

ב-Google צריך להבחין גם בין חוויות AI שונות. התיעוד שלה מציין ש-AI Overviews ו-AI Mode עשויים להשתמש בטכניקות ובמודלים שונים. השוואה בין חוויות שונות אינה יכולה לייחס את כל הפער לשפה.

מפרידים בין שפת המקור לרלוונטיות שלו

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

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

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

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

בונים בדיקה קטנה סביב שאלות אמיתיות

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

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

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

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

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

מסווגים את ההבדלים לפני שמציעים פתרון

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

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

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

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

מחברים כל בעיה לשינוי שאפשר להצדיק

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

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

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

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

מסכמים מה למדנו ומה עדיין לא ידוע

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

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