אינדוקס RAG של צ'אטים: חיפוש ב-Slack, Teams ו-Telegram

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

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

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

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

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

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

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

מה נותן חיפוש רוחבי בהתכתבות פנימית

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

נקודת חיפוש אחת במקום מעבר בין יישומים

שאילתה אחת יוצאת אל Slack, Teams ו-Telegram ומחזירה לא קישורים, אלא קטעים מוכנים עם המחבר והתאריך. המהנדס סוגר את הנושא בחלון אחד במקום ארבעה-שישה מעברים וניסוחים חוזרים. זמן התגובה לשאילתה פנימית יורד מ-10–15 דקות ל-1–2.

מהירות התגובה לשאילתה פנימית

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

האצת חניכה וניתוח תקלות לפי ההתכתבות

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

מצבי אינדוקס צ׳אטים: אצווה, זרימה, היברידי

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

מעבר אצווה על ההיסטוריה ומגבלותיו

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

עיבוד זרימה והיברידי

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

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

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

ביקורת מקורות והרשאות גישה

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

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

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

מארז האספקה: תצורות, סכימות, נהלי גישה

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

תצורות וסכימת זרימות הנתונים

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

מדיניות גישה, תפקידים והוראות

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

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

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

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

כיצד השתנו המדדים לפני ואחרי

• זמן חיפוש התשובה: 20-40 דקות של מעבר ידני בערוצים ← 1-2 דקות עד לקישור לענף הנדרש.
• חלק השאלות החוזרות: ירד בערך בחצי — התשובה נמצאת לפני שהאדם כותב לתמיכה.
• עומס על התמיכה: זרם הפניות האחידות ירד בכשליש בערך.
• ניהול: רשימת הערוצים המאונדקסים וכללי ההחרגה משתנים מהממשק, ללא בנייה מחדש.

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

במה שונה עיבוד זרימה מעיבוד אצווה בנפחים גדולים?

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

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

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

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

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

ספקות נפוצים: הרשאות גישה, תקופות שמירה, איכות התוצאות

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

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

מי מבחוץ יכול לקרוא את ההתכתבות של העובדים?

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

כיצד להשתכנע שאיכות התוצאות מספקת?

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

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

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

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

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