הטמעת חיפוש סמנטי במסמכים טקסטואליים

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

חיפוש סמנטי: מדוע בחירה לפי מילים אינה מוצאת את התשובה

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

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

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

מבנים שונים, חלקי דיבור שונים, אפס התאמה לפי מילים — ותוצאות ריקות בשאילתה החמישית-שישית מאלצות אנשים לחפש ידנית בתיקיות.

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

מה נותן החיפוש הסמנטי: אפקט במדדים מדידים

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

לאחר המעבר לחיפוש משמעותי עם תכנית היברידית — סינון לקסיקלי בתוספת חיפוש לפי ייצוג וקטורי — המדד עולה ל-75–90%. אנו עובדים על OpenSearch: שני המצבים חיים באינדקס אחד, אין צורך במערכת שנייה.

המדד השני — זמן עד למסמך השימושי הראשון. בעבר עובד בילה 10–20 דקות במעבר על קישורים לא רלוונטיים או הלך לשאול עמית; כיום התוצאות לפי משמעות סוגרות את הנושא בדקה-שתיים.

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

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

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

השוואת גישות: אינדקס וקטורי, היברידי וכללים

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

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

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

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

כיצד אנו מטמיעים: שלבי העבודה מהביקורת ועד המסירה

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

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

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

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

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

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

מקרה בוחן: זמן מציאת התשובה במאגר המסמכים הצטמצם

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

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

מה שינו

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

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

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

מה יקרה עם מסמכים "מלוכלכים" — טבלאות, כותרות עמוד, שורות קרועות?

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

ומה אם המסמכים הם סריקות ללא שכבה טקסטואלית?

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

כיצד להבדיל הרשאות כדי שעובד לא יראה את המיותר?

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

האם אפשר לפרוס את החיפוש במתחם פנימי?

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

מה קורה בעת עדכון בסיס הידע?

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

כיצד להוכיח שאיכות החיפוש אכן עלתה?

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

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

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

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

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