איסוף, העשרה וסינון באמצעות מטא-דאטה

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

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

1. מטא-דאטה דטרמיניסטי: אלו הם הנתונים הפיזיים הקשיחים שנשלפים באופן ישיר מרכיב ניתוח המסמכים, ה-Data Analyzer או ספריות ה-Parsing. מטא-דאטה זה כולל מזהים הכרחיים למערכת כגון: מזהה מסמך (document_id), מספר מזהה לנתח ספציפי (chunk_index), מספר עמוד, כתובת המקור (source_url), חותמת זמן של יצירת המסמך, ותגיות הרשאה של בקרת גישה (למשל organization_id או רמת חסיון). נוכחותם של שדות אלו אינה המלצה אלא חובה שמשמשת לצורך ניהול שוטף, רענון מידע תקופתי כמו מחיקות, הכנסות, עדכונים, וכן לשם מתן יכולת ציטוט מדוייק למשתמש מניין נשאב המידע.

   
   

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

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

ההשלכה על מערכת הניתוב ושירות החיפוש היא שעל הארכיטקטורה לתמוך במנגנון שמתרגם שאלת משתמש בשפה טבעית לשאילתת פילטור מובנית עוד בטרם ביצוע החיפוש. ישנו Design Pattern למטרה זו הוא Self-Querying Retrieval. על ידי שימוש ב-LLM כסוכן מתכנן-חיפוש, המערכת מקבלת שאלה דוגמת "מהם נהלי אישור ההוצאות בחברת שקר-כלשהו משנת 2025?", ומייצרת שאילתת חיפוש וקטורי עם פרמטרים מובנים: {query: "נהלי אישור הוצאות", filters: {"organization": "sortOfLie corp", "year": "2025"}}.

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

נסכם:

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

איסוף, העשרה וסינון באמצעות מטא-דאטה

צריכים עזרה עם AI/GenAI/AgenticAI/AI Platform ועם מעבר מהוכחת יכולת לעבודה בסקייל מלא באנטרפרייז? זקוקים לשותף טכנולוגי עתיר ניסיון שיודע לספק שירותי מחקר ופיתוח Hands-on, מארגוני אנטרפרייז ועד סטארט-אפים, על מנת להוציא חזון אלגוריתמי שלכם מהכוח אל הפועל? רוצים מחקר אלגוריתמי יישומי? הבה נדבר!

שלמה יונה,

מייסד ומדען ראשי, 

מתמטיקאי מחקר ופיתוח בע"מ

053-7326360

shlomo.yona@mathematic.ai

https://mathematic.ai

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

A technical deep dive about Mathematic.ai