מערכות בינה מלאכותית לניהול ידע - איך בונים "מוח שני" לחברה?

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

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

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

למה הידע הארגוני הופך לבעיה ככל שהחברה גדלה?

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

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

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

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

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

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

התהליך נראה כך:

• העובד מזין שאלה בשפה טבעית.

• המערכת בודקת מי המשתמש ולאיזה מידע הוא רשאי לגשת.

• מנוע החיפוש מאתר מסמכים, פסקאות, רשומות או תמלולים הקשורים לשאלה.

• המודל מקבל את המידע שנמצא ומנסח ממנו תשובה ברורה.

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

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

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

מה ההבדל בין מערכת ניהול ידע רגילה למערכת מבוססת AI?

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

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

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

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

איזה מידע אפשר להזין למערכת ניהול ידע בארגון?

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

מקורות אפשריים כוללים:

• נהלי עבודה, הוראות ותהליכים פנימיים.

• מצגות, מסמכי Word, קובצי PDF וגיליונות נתונים.

• בריפים, הצעות מחיר, חוזים ותבניות מאושרות.

• סיכומי פגישות ותמלולים מ-Zoom, Google Meet, Teams או כלי סיכום פגישות AI.

• מידע על לקוחות, עסקאות ופניות ממערכת ה-CRM.

• קריאות שירות, שאלות נפוצות והתכתבויות עם מחלקת התמיכה.

• שיחות רלוונטיות מ-Slack, Microsoft Teams או ערוצי תקשורת ארגוניים אחרים.

• התכתבויות מייל, בכפוף להרשאות ולמדיניות הפרטיות של החברה.

• תיעוד פרויקטים ממערכות כמו Asana, Jira, Monday או ClickUp.

• מפרטי מוצרים, מחירונים, קטלוגים ומסמכים טכניים.

• תיעוד החלטות הנהלה, כולל הסיבה להחלטה ומועד כניסתה לתוקף.

• ידע מקצועי של עובדים ותיקים שנאסף באמצעות ראיונות ותהליכי שימור ידע.

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

איך "המוח השני" של החברה נראה בפועל?

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

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

• מה היעדים העסקיים המרכזיים של הלקוח?

• אילו מסרים הלקוח ביקש להדגיש ואילו ניסוחים הוא פסל?

• מה סוכם בפגישה האחרונה ומי אחראי לכל משימה?

• אילו קמפיינים רצו בעבר ומה היו התוצאות שלהם?

• האם הלקוח אישר את התקציב ואת לוח הזמנים?

• כתוב טיוטת תוכנית עבודה בהתבסס על הבריף ועל ההחלטות האחרונות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אפיון מערכת ניהול ידע: מה צריך להגדיר לפני שבוחרים כלי?

אפיון מערכת ניהול ידע אינו מתחיל בשאלה אם לבחור ב-Notion, ב-Microsoft, ב-Google או בפיתוח מותאם. הוא מתחיל בהבנת הבעיות שהמערכת אמורה לפתור. בחירת כלי לפני הגדרת הצרכים עלולה להוביל למערכת מרשימה שאינה משתלבת בעבודה היומיומית.

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

• מי ישתמש במערכת ובאילו מצבים?

• אילו שאלות העובדים שואלים שוב ושוב?

• מהן המשימות שהיום דורשות חיפוש ידני ממושך?

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

• מי רשאי לצפות בכל סוג של מידע?

• מי אחראי לעדכן, לאשר או למחוק כל מקור?

• כמה מהר מידע חדש צריך להופיע במערכת?

• האם המערכת רק עונה על שאלות או גם מבצעת פעולות?

• האם נדרשות הפניות מדויקות למסמכים, משפטים או רשומות?

• כיצד תימדד הצלחת הפרויקט?

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

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

איך בונים מערכת ניהול ידע ארגוני עם AI שלב אחר שלב?

שלב 1: מתחילים בשאלות ולא במסמכים

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

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

שלב 2: ממפים ומנקים את מקורות הידע

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

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

שלב 3: מגדירים הרשאות וגבולות מידע

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

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

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

שלב 4: בוחרים את סוג הפתרון

ארגונים קטנים יכולים להתחיל בכלי שמאפשר להעלות מקורות ולשאול עליהם שאלות. ארגונים שהמידע שלהם כבר נמצא ב-Notion, Google Workspace או Microsoft 365 יכולים להעדיף פתרון שמתחבר לסביבה הקיימת. חברות גדולות או מורכבות עשויות להזדקק לפלטפורמת חיפוש ארגונית או למערכת RAG מותאמת.

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

שלב 5: מגדירים כיצד המערכת צריכה לענות

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

פרומפט בסיסי למערכת יכול להיראות כך:

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

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

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

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

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

שלב 7: משיקים לקבוצה קטנה ומטמיעים הרגלי שימוש

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

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

שלב 8: מתחזקים את הידע באופן קבוע

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

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

באילו כלים אפשר להשתמש להקמת המערכת?

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

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

לארגונים שעובדים ב-Notion: ‏Notion Enterprise Search מאפשר לחפש במרחב העבודה ובמקורות מחוברים. לפי התיעוד של Notion, ניתן לחבר מקורות כמו Slack, Microsoft Teams, Google Drive ו-Jira ולצמצם את החיפוש למקור מסוים.

לארגונים בסביבת Microsoft: שילוב של SharePoint, Microsoft 365 Copilot או Copilot Studio יכול להתאים כאשר מסמכים, מיילים, פגישות והרשאות כבר מנוהלים בתוך Microsoft 365. היתרון הוא שימוש בזהויות ובהרשאות הקיימות, אך הצלחת המערכת תלויה מאוד בסדר ובאיכות ההרשאות ב-SharePoint ובשאר השירותים.

לארגונים בסביבת Google: ‏Google Workspace עם Gemini יכול לסייע בעבודה עם מידע מתוך Gmail, Drive, Docs, Sheets, Slides ו-Chat, בהתאם ליכולות שהוגדרו על ידי מנהל המערכת.

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

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

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

איך שומרים על אבטחת מידע, פרטיות ואמינות?

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

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

עקרונות מרכזיים שכדאי ליישם:

• מתן גישה לפי תפקיד ולפי עקרון ההרשאה המינימלית.

• הפרדה בין מידע כללי, מידע חסוי ומידע רגיש במיוחד.

• שימוש בהזדהות ארגונית ובאימות רב-שלבי.

• הצגת מקורות לצד כל תשובה מהותית.

• שמירת יומן פעילות לצורך בקרה וחקירת תקלות.

• קביעת מדיניות מחיקה, שמירה ועדכון של מידע.

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

• ביצוע בדיקות הרשאה עם משתמשים מתפקידים שונים.

• השארת החלטות משפטיות, רפואיות, פיננסיות או משמעתיות לבקרה אנושית מוסמכת.

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

איך מונעים מהמערכת להמציא תשובות?

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

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

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

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

טעויות נפוצות בהקמת מערכת ניהול ידע

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

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

• מתעלמים מההרשאות הקיימות: ה-AI עלול להנגיש במהירות מידע שכבר היה משותף בצורה רחבה מדי.

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

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

• לא ממנים אחראי: ללא בעלים לתוכן ולמערכת, המקורות מתיישנים והאמון נשחק.

• מצפים שהעובדים ישנו הרגלים לבד: יש לשלב את המערכת בתהליכי העבודה וללמד את הצוות כיצד להשתמש בה.

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

כיצד מודדים אם מערכת ניהול הידע מצליחה?

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

מדדים שימושיים כוללים:

• שיעור העובדים שמשתמשים במערכת באופן קבוע.

• זמן ממוצע לקבלת תשובה לפני ואחרי ההשקה.

• אחוז השאלות שקיבלו תשובה מבוססת מקור.

• מספר השאלות שלא נמצא להן מענה.

• שיעור התשובות שסומנו כשגויות או לא מספקות.

• מספר המסמכים הישנים או חסרי הבעלים שהתגלו.

• קיצור זמן ההכשרה והקליטה של עובדים חדשים.

• הפחתה במספר הפניות החוזרות למנהלים ולמומחים פנימיים.

• שביעות רצון העובדים ואמון בתשובות המערכת.

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

ממאגר מסמכים למוח השני של הארגון

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

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

חיפוש מידע הוא רק אחד התהליכים ששווה לייעל - המדריך על קיצור תהליכי עבודה עם AI מראה איך מזהים את שאר המשימות החוזרות בעסק ומודדים את החיסכון בפועל.

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