לקוח שואל שאלה פשוטה על חוזה, מדריך או נתון פנימי. המערכת עונה בביטחון, אבל מצטטת מסמך ישן, מפספסת חריג חשוב או גרוע יותר - מחזירה מידע מחשבון של לקוח אחר. זו הסיבה שהשאלה איך להטמיע חיפוש חכם במסמכים אינה מתחילה בבחירת מודל שפה. היא מתחילה בהגדרה מדויקת של מידע, הרשאות, איכות ותפעול.
במוצר SaaS פעיל, חיפוש מסמכים הוא תשתית מוצרית. משתמשים מצפים למצוא תשובה במהירות, להבין על איזה מקור היא מבוססת, ולדעת שהמערכת לא חשפה מידע שלא היו אמורים לראות. אם משלבים גם ממשק שיחה מבוסס RAG, הקיצור של Retrieval-Augmented Generation, החיפוש הופך לחלק ישיר מאיכות התשובה שהמשתמש מקבל.
מהו חיפוש חכם במסמכים בפועל
חיפוש מילות מפתח מחפש התאמה טקסטואלית: המשתמש כתב מונח מסוים, והמערכת מחזירה מסמכים שבהם הוא מופיע. זה עדיין שימושי מאוד, במיוחד כשמחפשים מספר הזמנה, שם לקוח, מזהה טכני או נוסח משפטי מדויק.
חיפוש חכם מוסיף שכבה סמנטית. הוא מנסה להבין את משמעות השאלה גם כשהניסוח שונה מהניסוח במסמך. לדוגמה, משתמש ששואל "מתי אפשר לבטל?" אמור למצוא את סעיף תנאי הביטול, גם אם המסמך משתמש במילים "סיום התקשרות" או "הפסקת שירות".
במערכת טובה, אין הכרח לבחור בין שתי השיטות. לרוב משלבים חיפוש לקסיקלי, כלומר מילות מפתח, עם חיפוש וקטורי שמייצג משמעות. השילוב הזה נקרא לעיתים hybrid search. הוא מצמצם פספוסים של מונחים מדויקים בלי לוותר על הבנת ההקשר. אבל גם מנוע חיפוש משולב לא יפתור מסמכים מיובאים בצורה שגויה או מודל הרשאות שלא הוגדר נכון.
לפני ההטמעה: להגדיר מה המשתמש באמת צריך למצוא
הטעות הנפוצה היא להתחיל מיצירת embeddings - ייצוג מספרי של טקסט לצורך חיפוש סמנטי - לפני שממפים את התרחישים. בפועל, צריך להבין אילו שאלות המשתמשים שואלים, באילו מסמכים נמצאת התשובה, ומה נחשב תשובה שימושית.
יש הבדל מהותי בין חיפוש בתוך מאגר נהלים פנימי, חיפוש בקבצי לקוח, וחיפוש במסמכי תמיכה שמשותפים לכלל החשבונות. לכל אחד מהם יש בעלות מידע שונה, מחזור עדכון שונה וסיכוני הרשאות אחרים. אם מקור נתונים הוא דינמי, למשל רשומה שמגיעה מ-API, לעיתים עדיף לא להמיר אותו למסמך סטטי כלל. אפשר להציג אותו דרך שאילתה מובנית ומבוקרת, במקום להסתמך על טקסט שהוזן לאינדקס לפני שבוע.
בשלב הזה אנו ממליצים להגדיר גם את גבולות היכולת. האם המערכת אמורה להחזיר קטעים ממסמכים, לסכם אותם, או לענות בשפה חופשית? האם היא יכולה להסיק מסקנה, או רק להציג מידע מפורש? ככל שהפעולה רחבה יותר, כך נדרשים יותר בדיקות, הגנות והסברים למשתמש.
הכנת המסמכים: איכות הקלט קובעת את איכות החיפוש
מסמך PDF שנראה תקין לעין אנושית לא בהכרח מתאים לחיפוש. ייתכן שהוא סריקה ללא שכבת טקסט, שהטבלאות בו פורקו לסדר מילים לא הגיוני, או שכותרות וגרסאות חסרות. כאשר המערכת מאנדקסת טקסט פגום, היא מחפשת בתוך טקסט פגום.
הצעד הראשון הוא תהליך ingestion מסודר: חילוץ הטקסט, זיהוי שפה, ניקוי תווים מיותרים, טיפול ב-OCR לקבצים סרוקים, ושמירת מטא-דאטה. המטא-דאטה כולל בדרך כלל מקור, מזהה מסמך, גרסה, תאריך עדכון, סוג מסמך, בעלות וגבולות גישה. בלי הנתונים האלה, יהיה קשה מאוד להסביר תשובה, למחוק מידע או להגביל גישה בצורה עקבית.
לאחר מכן מפצלים מסמכים לקטעים, או chunks. חלוקה לפי מספר תווים בלבד מהירה ליישום, אך לעיתים שוברת פסקה או טבלה באמצע. בדרך כלל עדיף לפצל לפי מבנה המסמך: כותרות, סעיפים, פסקאות וגבולות לוגיים אחרים. קטע קטן מדי מאבד הקשר. קטע גדול מדי מכניס רעש לתוצאות, מגדיל עלויות ומקשה על מודל השפה להתמקד.
אין גודל אחד נכון לכל מסמך. מדריך טכני, חוזה ושאלות נפוצות דורשים חלוקה שונה. לכן בודקים את ההחלטה על סט שאלות אמיתי, ולא לפי תחושה לאחר העלאה ראשונה של קבצים.
איך להטמיע חיפוש חכם במסמכים בלי לעקוף הרשאות
במערכת מרובת לקוחות, הרשאות אינן פילטר קוסמטי שמפעילים בסוף. הן חייבות להיות חלק מהשאילתה עצמה. לפני שמנוע החיפוש מחזיר מועמדים, עליו לקבל את ההקשר של המשתמש: מזהה חשבון, תפקיד, צוות, פרויקט ולעיתים גם הרשאה ברמת מסמך או תיקייה.
הכלל המעשי הוא פשוט: מסמך שלא היה מופיע בתוצאת חיפוש רגילה לא אמור להגיע גם לשלב ההקשר של RAG. אסור להחזיר אותו למודל ואז לבקש מהמודל "לא להשתמש בו". מודל שפה אינו מנגנון הרשאות, והנחיה בטקסט אינה תחליף לאכיפה בצד השרת.
חשוב לשמור את נתוני ההרשאה גם באינדקס, ולוודא שהם מתעדכנים כאשר משתמש מחליף תפקיד, מסמך מועבר, או לקוח נמחק. במוצרים מסוימים כדאי להפריד אינדקסים לפי tenant. זה יכול להקל על בידוד נתונים, אך מגדיל מורכבות תפעולית ועלול לייקר ניהול של הרבה חשבונות קטנים. במקרים אחרים, אינדקס משותף עם סינון מטא-דאטה קשיח מתאים יותר. הבחירה תלויה בכמות המידע, דפוסי הגישה והדרישות הרגולטוריות שלכם.
תוצאות, ציטוטים ותשובות: לא אותו דבר
חיפוש טוב מחזיר תוצאות רלוונטיות. תשובת RAG טובה משתמשת בתוצאות האלה כדי לנסח מענה, בלי להוסיף עובדות שלא קיימות במקור. אלו שני מדדי איכות שונים, ולכן צריך למדוד אותם בנפרד.
בתצוגת חיפוש רגילה, כדאי להציג כותרת מסמך, קטע רלוונטי, תאריך או גרסה, והקשר שמסביר מדוע התוצאה הופיעה. בממשק שיחה, התשובה צריכה לכלול citations ברורים: שם המסמך, סעיף או עמוד אם אפשר, ומזהה יציב שמאפשר למשתמש לפתוח את המקור המתאים במערכת.
ציטוט אינו קישוט של אמון. הוא כלי בדיקה. המשתמש יכול לראות אם התשובה נשענת על מקור עדכני, וצוות המוצר יכול להבין אם בעיית האיכות נובעת מאחזור לא נכון, ממסמך לא תקין או מניסוח שגוי של המודל. אם אין מקור מספיק, עדיף שהמערכת תגיד שאין לה בסיס לתשובה ותציע חיפוש חלופי, מאשר שתשלים תשובה משוערת.
מדידה לפני שחרור ואחריו
"נראה שעובד" אינו קריטריון מספיק לשינוי במנוע חיפוש או ב-RAG. שינוי בחלוקת קטעים, מודל embeddings, סף רלוונטיות או prompt יכול לשפר חלק מהשאלות ולהחמיר אחרות. בלי evals, כלומר סט בדיקות שיטתי, קשה לדעת מה באמת קרה.
בנו סט קטן אך מייצג של שאלות אמיתיות: שאלות שיש להן תשובה ברורה, שאלות עם ניסוחים חלופיים, שאלות שצריכות להחזיר "לא נמצא", ושאלות שמנסות לגשת למידע ללא הרשאה. לכל שאלה הגדירו את המקור המצופה, את תנאי הגישה ואת סוג המענה הרצוי.
הבדיקות צריכות לעקוב לפחות אחרי ארבעה דברים:
- האם המסמך הנכון נכנס לתוצאות הראשונות.
- האם התשובה נאמנה למקורות שסופקו לה.
- האם הציטוטים מובילים למסמך ולמקטע הנכונים.
- האם משתמש ללא הרשאה לא מקבל תוצאה, הקשר או ציטוט אסור.
לצד איכות, מודדים זמן תגובה ועלות. אפשר לשפר איכות באמצעות שליפת יותר קטעים או שימוש במודל גדול יותר, אבל המחיר עשוי להיות תשובה איטית ויקרה יותר. לעיתים re-ranking, שלב שמדרג מחדש את התוצאות המובילות, נותן שיפור ממוקד בעלות נמוכה יותר. לעיתים דווקא צמצום ההקשר משפר גם מהירות וגם דיוק, משום שהמודל מקבל פחות רעש.
תפעול שוטף: אינדקס שלא מתעדכן הופך לחוב מוצרי
אחרי העלייה לאוויר, העבודה לא מסתיימת. צריך לדעת מתי מסמך השתנה, נמחק או עבר בעלות, ולהפעיל עדכון אינדקס אמין. כדאי לשמור גרסאות ולמנוע מצב שבו תוצאות ישנות נשארות זמינות לאחר שהמסמך המקורי הוסר.
לוגים צריכים לאפשר חקירה של תשובה בעייתית בלי לחשוף תוכן רגיש לכל מי שפותח אותם. שמרו מזהי בקשה, גרסת אינדקס, מסמכים שנשלפו, החלטות סינון וזמני ביצוע. את תוכן המסמכים עצמם יש לנהל בזהירות ובהתאם למדיניות האבטחה שלכם. גם כאן יש איזון: לוגים מפורטים מקלים על דיבוג, אבל מגדילים את משטח החשיפה.
חיפוש חכם אמין אינו תכונה שמחברים פעם אחת ומסמנים עליה וי. הוא מערכת שמבוססת על מידע נקי, הרשאות שנאכפות לפני האחזור, מקורות גלויים, בדיקות איכות ומדדים תפעוליים. אם יש לכם חיפוש או RAG שכבר חי במוצר ואינכם בטוחים מה באמת קורה תחת עומס, בעדכוני מסמכים או בין חשבונות שונים, אפשר להתחיל בסקירה קצרה דרך טופס יצירת הקשר באתר של DevCo Solutions.