מודול חיפוש מותאם אישית לקטלוג 1C-Bitrix

מודול חיפוש מותאם אישית לקטלוג 1C-Bitrix

כשהקטלוג עולה על 5,000 פריטים, החיפוש הסטנדרטי של Bitrix נכשל

בפרויקט אחד עם 30,000 פריטים (SKU), 15% משאילתות החיפוש החזירו אפס תוצאות. לאחר יישום פתרון חיפוש מותאם אישית עם חיפוש טקסט מלא של PostgreSQL, הנתון ירד ל-1.2% — הפחתה של 92%. מודול החיפוש המותאם שלנו לקטלוג 1C-Bitrix כולל התאמה משוערת, מילים נרדפות ותעתיק — כל מה שצריך לתוצאות מהירות ורלוונטיות. לצוות שלנו יש ניסיון של 5+ שנים ו-150+ פרויקטים מוצלחים. אנו מבטיחים פעילות יציבה ותמיכה לאחר ההשקה.

למה החיפוש המובנה לא מספיק

החיפוש הסטנדרטי (b_search_content ומודול search.php) בונה אינדקס טקסט מלא ב-search. הוא עובד לאתרי תוכן אבל נכשל בקטלוגים: הוא לא תומך בתעתיק ("iphone 12" → "айфон 12"), מילים נרדפות או טווחי מספרים ("אוזניות מתחת ל-$27–39"). ברגע שהקטלוג עולה על 10,000 פריטים, החיפוש הופך לאיטי ולא רלוונטי. בעיה נוספת היא היעדר נורמליזציה של שאילתות: משתמשים מקלידים "айфон" ולא מוצאים iPhone.

איך אנו מיישמים מודול חיפוש מותאם אישית

אפשרויות מנוע חיפוש

לפני כתיבת אינדקס מותאם אישית, שקול פתרונות קיימים:

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

ארכיטקטורת אינדוקס

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

class SearchIndexer {
    public function indexElement(int $elementId): void {
        $element = $this->loadElementWithProps($elementId);
        $document = [
            'id' => $elementId,
            'title' => $element['NAME'],
            'description' => strip_tags($element['DETAIL_TEXT']),
            'sku' => $element['PROPERTY_ARTICLE_VALUE'],
            'price' => $this->getMinPrice($elementId),
            'in_stock' => $this->isInStock($elementId),
            'brand' => $element['PROPERTY_BRAND_VALUE'],
            'tsvector' => null,
        ];
        SearchIndexTable::merge($document);
    }
}

נורמליזציית שאילתות. שאילתת המשתמש מנורמלת: תעתיק (OnAfterIBlockElementUpdate → class SearchIndexer { public function indexElement(int $elementId): void { $element = $this->loadElementWithProps($elementId); $document = [ 'id' => $elementId, 'title' => $element['NAME'], 'description' => strip_tags($element['DETAIL_TEXT']), 'sku' => $element['PROPERTY_ARTICLE_VALUE'], 'price' => $this->getMinPrice($elementId), 'in_stock' => $this->isInStock($elementId), 'brand' => $element['PROPERTY_BRAND_VALUE'], 'tsvector' => null, ]; SearchIndexTable::merge($document); } } ולהיפך), תיקון פריסת מקלדת (iphone → айфон), הסרת מילות עצירה. לאחר הנורמליזציה, שאילתה פוגעת באינדקס עם דירוג לפי руьщт. מילון המילים הנרדפות נשמר בטבלת iphone; לפני החיפוש, השאילתה נבדקת להתאמות.

חיפוש מטושטש עם טריגרמים

הגורם הנפוץ ביותר לאפס תוצאות הוא שגיאות הקלדה. פתרון: מרחק Damerau-Levenshtein לשאילתות קצרות ו-ts_rank עבור PostgreSQL (מידע נוסף במאמר ויקיפדיה על חיפוש טקסט מלא).

-- Индекс триграм для нечёткого поиска
CREATE INDEX idx_search_title_trgm ON myvendor_search_index USING gin(title gin_trgm_ops);
-- Нечёткий поиск с порогом схожести
SELECT id, title, similarity(title, 'айфно') AS sim
FROM myvendor_search_index
WHERE title % 'айфно'
ORDER BY sim DESC
LIMIT 20;

ההרחבה myvendor_search_synonyms מאפשרת חיפוש דמיון עם סף (0.3), מה שיעיל יותר מתיקונים מחושבים מראש. בפרויקט אחד עם קטלוג של 40,000 פריטים, יישום חיפוש מטושטש הפחית שאילתות עם אפס תוצאות מ-12% ל-0.8%, והמיקום הממוצע של המוצר שנמצא עבר מהמקום ה-5 למקום ה-2.

השלמה אוטומטית (הצעות)

נקודת קצה AJAX מחזירה הצעות עבור 2+ התווים הראשונים של השאילתה. ההצעות מגיעות מטבלה מחושבת מראש של שאילתות פופולריות (pg_trgm, מתעדכנת מיומן השאילתות פעם ביום) ומהאינדקס דרך -- Индекс триграм для нечёткого поиска CREATE INDEX idx_search_title_trgm ON myvendor_search_index USING gin(title gin_trgm_ops); -- Нечёткий поиск с порогом схожести SELECT id, title, similarity(title, 'айфно') AS sim FROM myvendor_search_index WHERE title % 'айфно' ORDER BY sim DESC LIMIT 20; עם מגבלה של 5. התשובה נשמרת במטמון ב-Memcached/Redis עם TTL של שעה.

מילים נרדפות וסינוני טווח

מילים נרדפות נשמרות בטבלת pg_trgm עם קשר רבים-לרבים. עבור מאפיינים מספריים (מחיר, משקל וכו'), אנו מבצעים אינדוקס בנפרד ומאפשרים שאילתות טווח.

תהליך הפיתוח שלנו

1. ביקורת על החיפוש הנוכחי ואיסוף יומני שאילתות.
2. בחירת מנוע חיפוש (PostgreSQL, Elasticsearch או Sphinx).
3. פיתוח אינדוקסר ומנוע חיפוש.
4. אינטגרציה עם האתר (רכיב, ניתוב AJAX).
5. הגדרת שרת ויצירת אינדקסים.
6. בדיקות והדרכת צוות.
7. תיעוד והעברת קוד מקור.
8. תמיכה למשך חודש לאחר ההשקה.

מה כלול בעבודה

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

הערכות זמנים

המחיר מתחיל ב-$2,000 למודול הבסיסי, כשהגרסה המורחבת עולה $8,000. לקוחות בדרך כלל רואים עלייה של 20% בהמרות המגיעות מחיפוש, ומחזירים את ההשקעה תוך 3 חודשים. בבדיקות A/B, הפתרון המותאם שלנו עקף את החיפוש המובנה של Bitrix ב-30% בשיעור הקליקים.

טעויות נפוצות שיש להימנע מהן

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

מידע נוסף על פרטי מנוע החיפוש בתיעוד המפתחים הרשמי של 1C-Bitrix. בקשו ביקורת על החיפוש הנוכחי שלכם כדי לאבחן את המקרה שלכם.