חיפוש AI במסמכי תיעוד: RAG וחיפוש סמנטי

חיפוש סמנטי במסמכים: היכן זה נשבר

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

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

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

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

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

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

מה משתנה לאחר ההטמעה: זמן התשובה והדיוק

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

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

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

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

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

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

מצבי אינדוקס ותוצאות: השוואת גישות

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

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

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

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

שלבי ההטמעה: מביקורת הקורפוס ועד למסירה

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

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

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

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

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

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

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

מקרה בוחן: כיצד עלו דיוק התשובות ומהירות התוצאות

מקרה של הטמעת חיפוש סמנטי: מפעיל לוגיסטי Северный Путь מחזיק 40,000 עמודים של נהלים, הוראות תפעול לציוד וחוזים טיפוסיים. תשובות חיפשו ידנית: עובד הריץ חיפוש לפי מילות מפתח, פתח חמישה עד עשרה קבצים ובכל זאת הלך לברר אצל מחבר המסמך. הלקוח חיכה לתשובה 20–40 דקות, וחלק מהניסוחים העובדים נתנו מהזיכרון — בלי אימות מהמקור.

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

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

סט בקרה ואמינות התשובות

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

במה שונה התאמה וקטורית מהתאמה לפי מילים?

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

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

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

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

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

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

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

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

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

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

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

כיצד הרשאות גישה מיושמות על הקטעים?

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

האם אפשר לפרוס את החיפוש בקונטור סגור?

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

נדון במשימה: נכין הערכה ותוכנית עבודה

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

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

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

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

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