חיפוש באפליקציה אינו סולח לשגיאות הקלדה: כיצד זה שובר את המשפך
המשתמש מקליד «кроссовки nike air max 90», מפספס מקש אחד — «nike air maz 90» — ומקבל מסך «לא נמצא דבר». הוא לא יתקן את השאילתה: הוא סוגר את החיפוש, גולל בקטגוריות או עובר לאפליקציה אחרת.
שגיאת הקלדה אחת בשאילתת החיפוש קוטעת את הדרך להזמנה בנקודה היקרה ביותר במשפך, שבה המשתמש כבר יודע מה הוא רוצה לקנות.
מחיר התקלה הזו ניכר במטריקות: שיעור התוצאות הריקות עולה בשאילתות ארוכות עם שמות מותגים ומק"טים, והמרת החיפוש באפליקציה צונחת פי כמה בהשוואה לשאילתות ללא שגיאות. יחד עם זאת, החיפוש פורמלית עובד — האינדקס מגיב, הממשק לא קורס, בלוגים אין אף שגיאה. הבעיה אינה בכשל תשתיתי, אלא בכך ששכבת החיפוש אינה יודעת להתאים את קלט המשתמש לקטלוג האמיתי.
תיקון שגיאות הקלדה בחיפוש באמצעות AI סוגר את הפער הזה: המודל מזהה בזמן אמת מילה מעוותת, מאתר את שאילתת המוצר הסבירה ביותר ומחזיר תוצאות רלוונטיות במקום מסך ריק. איכות החיפוש באפליקציית המובייל מפסיקה להיות תלויה בדיוק ההקלדה במקלדת קטנה — ושם בדיוק טועה רוב המשתמשים.
בהמשך נפרק כיצד זה בנוי: אילו סוגי שגיאות אנו תופסים, היכן עובר הגבול בין תיקון לבין החלפת השאילתה, וכיצד אנו מודדים את ההשפעה על המשפך.
איך עובד תיקון שגיאות הקלדה ב-AI בחיפוש ומה משתנה
מצבי תיקון: מהחלפה ועד מודל שפה
הרמה הבסיסית — תיקון מילוני לפי מרחק עריכה: השאילתה נבדקת מול אינדקס של ניסוחים פופולריים, ובמקרה של אי-התאמה של 1-2 תווים מוצב הווריאנט הקרוב ביותר. זה זול וצפוי, אבל נשבר על שאילתות מחוברות ומתועתקות.
התאמה פונטית מכסה את המחלקה הזו: "айфон" ו-"iphone" מובאים לקוד צלילי משותף ומוצאים זה את זה, גם אם נכתבו באלפביתים שונים.
חיפוש מטושטש פועל לא במקום, אלא מעל: הוא לא כותב מחדש את השאילתה, אלא מרחיב את התוצאות — טוקנים עם שגיאות הקלדה עדיין משתתפים בדירוג, והמשתמש רואה תוצאות בלי מסך ריק.
מודל שפה לחיפוש מתחבר בשכבה האחרונה ופותר את מה שאי אפשר לתאר בכללים: משחזר משמעות לפי הקשר הביטוי, מבחין בין "кофе" ל-"кофта" בכתיב דומה, ומציע המשך.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| תיקון מילוני | קטלוג עם שמות יציבים, מילון שאילתות יציב | לא מתמודד עם קלטים מחוברים ומתועתקים |
| התאמה פונטית | קהל רב-לשוני, מותגים ושמות | התראות שווא במילים קצרות |
| חיפוש מטושטש | זנב ארוך של שאילתות, מגוון רחב | עומס גדל על אינדקס החיפוש |
| מודל שפה | שאילתות דיבוריות ומורכבות | נדרשת תיוג והערכה מחדש סדירה |
מדדי איכות החיפוש נלקחים לפני ואחרי: שיעור השאילתות עם תוצאות אפס, שיעור המעברים לכרטיס מחמשת התוצאות הראשונות, שיעור ההבהרות החוזרות של השאילתה. לפיהם רואים אם מחלקת הכשלים נעלמה או שהתיקון רק סידר מחדש את התוצאות. שכבות מפעילים אחת אחת ומשווים על אותו חתך שאילתות — אחרת אי אפשר להפריד את האפקט מעונתיות.
Elasticsearch
שלבי הטמעת תיקון שגיאות הקלדה בחיפוש באפליקציה
הטמעת תיקון שגיאות הקלדה מבוסס AI מתחילה לא מהמודל, אלא מהנתונים: בלי שאילתות אמיתיות של משתמשים כל תוכנית נשארת בגדר ניחוש. לכן הצעד הראשון הוא לייצא לוגים של חיפוש לתקופה שמספיקה לכיסוי קפיצות עונתיות, ולבדוק איזה חלק מהשאילתות מסתיים בתוצאות ריקות.
בדרך כלל דווקא שם מסתתרות שגיאות הקלדה, תעתיקים ומילים שנכתבו בצירוף — המשתמש לא מקבל דבר ועוזב את האפליקציה.
מכאן העבודה מתקדמת בשלבים, שכל אחד מהם מסתיים בארטיפקט שניתן לבדוק.
- ביקורת שאילתות חיפוש. מנתחים את הלוגים: שאילתות שכיחות, שיעור התוצאות הריקות, עיוותים אופייניים — תווים חסרים ומוחלפים, תווים מיותרים, פריסת מקלדת בסכמה לשונית שגויה. בפלט — חיתוך של שאילתות בעייתיות עם הערכה כמה תעבורה הן נוגעות בה.
- תכנון סכמת תיקון שגיאות הקלדה. קובעים היכן לבצע את התיקון: בכניסה לחיפוש, ברמת האינדקס או כהצעה "אולי התכוונת ל". בוחרים סף הפעלה כדי לא להחליף שאילתות נדירות אך תקינות — אחרת החיפוש יתחיל "לתקן" שמות מוצרים ומותגים.
- הגדרת חיפוש מקורב. מחברים מרחק עריכה והשוואה פונטית, מגדירים מילון חריגים לשמות מהקטלוג. בודקים על שאילתות היסטוריות: כמה שגיאות הקלדה נסגרות אוטומטית, כמה עוברות להצעה.
- בדיקת איכות החיפוש. מחשבים את שיעור השאילתות עם תוצאות רלוונטיות לא ריקות לפני ואחרי, בודקים את המיקום של התוצאה הרצויה. בנפרד בודקים ששאילתות תקינות לא החלו להיכתב מחדש — זה הסיכון העיקרי בספים אגרסיביים.
- מסירת הפתרון ללקוח. מוסרים את הסכמה המוגדרת, המילונים, תצורת הספים ומדדי האיכות, כדי שהצוות יוכל ללוות את החיפוש בלעדינו.
נקודת המפתח היא שלב הבדיקה: בלעדיו תיקון שגיאות הקלדה הופך בקלות למקור לשגיאות חדשות. אנחנו מריצים את שני החיתוכים על אותה קבוצת שאילתות, כדי שהאפקט יהיה מדיד ולא מורגש. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי השלבים האלה.
במה שונה חיפוש מטושטש מתיקון שגיאות הקלדה?
חיפוש מטושטש ותיקון שגיאות הקלדה פותרים משימות שונות, אף שברמת המשתמש הם נראים זהים — "נמצא מה שהתכוונתי". חיפוש מטושטש מרחיב את אזור ההתאמה: השאילתה מושווית לאינדקס לפי מרחק עריכה, מפתחות פונטיים או קרבה וקטורית, ובתוצאות מופיעות מחרוזות דומות.
תיקון שגיאות הקלדה פועל אחרת — הוא תחילה מביא את השאילתה לצורה הנכונה המשוערת, ורק לאחר מכן מחפש לפיה. ההבדל בין הגישות מתגלה ברגע שבו השאילתה אינה מכילה שגיאה, אך גם אין התאמה מדויקת בקטלוג.
חיפוש מטושטש מגביר את השלמות: הוא שולף מוצרים ומאמרים שהמשתמש אחרת לא היה רואה. המחיר לכך — ירידה בדיוק. בסף חלש נכנסות לתוצאות פריטים רחוקים במשמעות, והאדם גולל את הרשימה בלי לסמוך על התוצאה. בסף נוקשה חלק משגיאות ההקלדה האמיתיות אינן נתפסות, והשלמות חוזרת לרמה של חיפוש רגיל.
תיקון שגיאות הקלדה פועל למען הדיוק: השאילתה "אוזניות אלחוטיות" לאחר נרמול הופכת ל"אוזניות אלחוטיות", והחיפוש מתבצע לפי ניסוח נקי. כאן הסיכון אחר — הפעלה שגויה.
אם האלגוריתם "יתקן" שם מותג, מק"ט או מונח נדיר, המשתמש יקבל תוצאות לשאילתה שלא הציג, ויאבד אמון בחיפוש יותר מאשר מדף ריק.
בפועל משלבים את הגישות בצינור עיבוד. תחילה השאילתה עוברת נרמול ותיקון שגיאות הקלדה לפי מילון וזוגות תדירות — כך מוסר הרעש. לאחר מכן לפי השאילתה המנוקה מופעל חיפוש מטושטש עם סף נשלט, כדי להשלים פריטים קרובים.
הסף נבחר לפי מדדים: שיעור השאילתות ללא תוצאה, שיעור המעברים מהתוצאות, שיעור החידודים של השאילתה. רק לפי המספרים האלה נראה היכן נגמרת השלמות המועילה ומתחיל הזבל.
עבור אפליקציה לנייד זה קריטי: המסך צר, המשתמש אינו גולל רשימות ארוכות ועוזב לאחר התוצאה הכושלת הראשונה. לכן תיקון שגיאות הקלדה נשמר שמרני — הוא אינו אמור לשנות שאילתות שכבר מניבות תוצאה — וחיפוש מטושטש מופעל כשכבה שנייה עם הגבלה על מספר המועמדים.
מקרה בוחן: כיצד תיקון שגיאות הקלדה העלה את שיעור ההמרה בחיפוש
הלקוח — שירות עם קטלוג של עשרות אלפי פריטים וחיפוש שמחזיק את עיקר ההזמנות. הנתונים האנליטיים הראו: חלק ניכר מהשאילתות הסתיים בתוצאות ריקות או במעבר למסך השני-שלישי.
הסיבה התבררה לא כרלוונטיות, אלא כשגיאות הקלדה ופריסת מקלדת — המשתמש מקליד "אייפון צ'קחול", המערכת מחפשת התאמה מדויקת ומחזירה אפס. כל שאילתה כזו — הזמנה אבודה שאף אחד לא רואה בדוחות, כי מבחינה פורמלית החיפוש "עבד".
מה היה לפני ההטמעה
הפקנו חתך לפי לוגים על פני מספר שבועות: שיעור השאילתות המוצלחות עמד על כ-71%, תוצאות ריקות — בסביבות 18% מכלל הפניות לחיפוש, וחלק נוסף מהמשתמשים קיבל תוצאות אך לא מצא את מבוקשו ועזב. שיעור ההמרה של חיפוש להזמנה — 4.2%.
בנפרד חישבנו את שיעור השאילתות עם סימני שגיאת הקלדה או פריסת מקלדת מעורבת: הוא התברר גבוה מכפי שהצוות הניח, וגדל במובייל, שבו המקלדת מפספסת לעתים קרובות יותר.
מה שינינו
הטמענו שכבת תיקון שגיאות הקלדה מבוססת AI לפני מנוע החיפוש: המודל ממיר את השאילתה לצורת המילון, מתחשב בפריסת המקלדת ובקרבה פונטית, ומקבל החלטה על תיקון רק כאשר יש ודאות מספקת — אחרת השאילתה עוברת כפי שהיא, כדי לא להחליף שמות נדירים אך תקפים. הגרסה המתוקנת אינה מחליפה את המקורית: המשתמש רואה "אולי התכוונת ל…" ויכול לחזור לגרסה שלו.
במקביל הוספנו תיעוד לוגים של זוגות "שאילתה → תיקון → תוצאה", כדי לראות היכן המודל טועה. זה יצר מעגל מבוקר: מקרים שנויים במחלוקת מגיעים לבדיקה, המילון מתרחב, והאיכות עולה בלי אימון מחדש מאפס.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| שיעור השאילתות המוצלחות | ~71% | ~89% |
| תוצאות ריקות | ~18% | ~6% |
| שיעור ההמרה של חיפוש להזמנה | 4.2% | 5.6% |
| שיעור השאילתות עם תיקון | — | ~14% |
העלייה בשיעור ההמרה של החיפוש הניבה תוספת להזמנות בלי שינויים בקטלוג ובמחירים — האפקט הגיע מהתנועה הקיימת ממילא. תוצאות ריקות חדלו להיות אזור הפסד "שקט": רואים אותן בניטור וניתן לנתח אותן נקודתית.
Elasticsearch שימש כמנוע החיפוש, ואת שכבת התיקון הצבנו לפניו — כך שהפתרון אינו תלוי בלוגיקה הפנימית של החיפוש וניתן להעבירו לסטאק אחר.
ספקות לגבי תאימות, מיגרציה והרשאות גישה — בואו נדון במשימה
הספק העיקרי של הלקוח נשמע כך: "יש לנו כבר חיפוש שעובד, והוא מספק אותנו — האם תיקון שגיאות הכתיב מבוסס AI ישבור אותו". אנו עונים לעניין: שכבת תיקון שגיאות הכתיב מותקנת לפני מנוע החיפוש הנוכחי ואינה מחליפה אותו.
השאילתה עוברת נרמול, הגרסה המתוקנת נשלחת לאינדקס הקיים, ואם רמת הביטחון של המודל נמוכה מהסף — החיפוש פועל לפי המחרוזת המקורית, כבעבר. התאימות לחיפוש הנוכחי נשמרת ברמת חוזה השאילתה, ולכן אין צורך לכתוב מחדש את לוגיקת התוצאות.
מה אם יהיה צורך לבנות מחדש את האינדקס? מיגרציה של אינדקס החיפוש מתבצעת במקביל: האינדקס החדש נבנה לצד הישן, והתעבורה מועברת לאחר השוואת תוצאות על מדגם בקרה של שאילתות. החזרת שינויים לאחור — זה מעבר חזרה לאינדקס הקודם, ולא שחזור מגיבוי, ולכן אורך דקות.
הרשאות גישה לנתונים ניתנות לפי עקרון המינימום ההכרחי: שירות תיקון שגיאות הכתיב רואה רק מחרוזות חיפוש, ללא קישור לחשבונות משתמשים ולהיסטוריית הזמנות.
האם ניתן להטמיע תיקון שגיאות כתיב ללא עצירת החיפוש?
כן. השכבה פועלת במצב תצפית: תחילה היא רק מתעדת אילו שאילתות הייתה מתקנת, ואנו משווים זאת לתוצאות בפועל. המעבר למצב מבצעי — שלב נפרד עם החזרה לאחור מיידית. המשתמש לא מבחין בשום השבתה.
בסיום ההטמעה הלקוח מקבל לידיו:
- קונפיגורציות של שכבת תיקון שגיאות הכתיב עם ספי ביטחון וכללי עקיפה;
- תרשים מעבר השאילתה מהקלט ועד לתוצאות עם נקודות תיעוד;
- מדיניות גישה לנתוני חיפוש והפרדת תפקידים;
- נוהל מיגרציה של האינדקס והליך החזרה לאחור עם קריטריונים להפעלה;
- תיעוד החיפוש: מילונים, כללי נרמול, מדדי איכות;
- לוח בקרה עם שיעור השאילתות שתוקנו והגידול במעברים מוצלחים.
תארו את סכמת החיפוש הנוכחית שלכם ואת מגבלות הגישה — נחזור עם הערכה ותוכנית הטמעה.
לוחות זמנים ליישום תיקון שגיאות הקלדה לפי שלבים
יישום תיקון שגיאות הקלדה מבוסס AI בחיפוש מתפרס על שלבים עם משך צפוי — מה� audits של שאילתות חיפוש ועד לפריסה לכלל הקהל.
לוחות הזמנים המשוערים שלהלן ניתנים עבור אפליקציה טיפוסית עם תוצאות חיפוש מבוססות; על תוכנית היישום הסופית משפיעים נפח לוגים של שאילתות, מספר שפות הממשק ודרישות לפרטיות נתונים.
משך הכיוונון תלוי לא כל כך במודל אלא באיכות הסימון: אם בלוגים יש הרבה שאילתות קצרות בשפות מעורבות, שלב הכנת הנתונים מתארך.
את תוכנית היישום אנחנו בונים כך שכל שלב יניב תוצאה ניתנת לבדיקה — לאחר ה-audit רואים איזה חלק מההחמצות מכסה התיקון, לאחר האינטגרציה — כיצד משתנה חלק החיפושים המוצלחים.
השלבים מתנהלים בחפיפה חלקית: את הכנת הנתונים אפשר להתחיל לפני סיום ה-audit, ואת הבדיקות — במקביל לאימון הנוסף. לכן משך היישום הכולל בדרך כלל קצר מסכום השלבים. תארו את תוצאות החיפוש שלכם ואת נפח הלוגים — נחזור עם הערכה ותוכנית מותאמת למקרה שלכם.