מאגר ידע ל־AI בלי תשובות ישנות: דף עבודה לעדכניות, הרשאות ומקורות

התשובה הישירה

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

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

קלט, פלט ובעלי תפקיד

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

הפלט הוא תשובה בעלת מבנה שאפשר לבדוק: תשובה קצרה; המקורות שעליהם נשענה; גרסה או תאריך של כל מקור; מגבלות או סתירות; ומצב החלטה — answered, needs-clarification, conflict או no-valid-source. בתהליך רגיש אין להפוך ציטוט טכני לאישור מקצועי: בעל התוכן בודק את המשמעות, ואחראי ההרשאות בודק מי רשאי לראות אותה.

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

1. בונים פנקס מקורות לפני אינדקס

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

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

2. מפרידים תוכן פעיל, היסטורי וטיוטה

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

מטא־דאטה שימושי כולל לפחות source_id, owner, audience, status, effective_from, reviewed_at, version ו־supersedes. מערכות חיפוש מסוימות מאפשרות סינון תוצאות לפי מאפייני קובץ, אך היכולת הטכנית אינה קובעת את מדיניות הארגון. הגדירו קודם את משמעות השדות ואת מי שרשאי לשנותם, ורק אז מימשו את המסננים במוצר שנבחר.

3. משמרים הרשאות מקצה לקצה

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

בדקו גם הרשאות קיימות במקור. מוצר שמכבד הרשאות משתמש עדיין עלול להחזיר מידע שנשתף בעבר לקבוצה רחבה מדי. תיעוד Microsoft, למשל, מסביר שבקרות SharePoint ו־OneDrive משפיעות על גילוי המידע בלי לשנות הרשאות משתמש, ושמדיניות מחזור חיים ושיתוף מסייעת לצמצום שיתוף־יתר. זו עובדה על Microsoft 365 Copilot, לא הבטחה לגבי כל כלי RAG.

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

4. מתכננים קליטה שניתנת לאימות

צינור טיפוסי כולל קליטת קבצים, חילוץ טקסט, חלוקה למקטעים, יצירת ייצוג לחיפוש, אינדוקס ושליפה. תיעוד Google ל־RAG Engine מציג שלבים דומים: ingestion, transformation, embeddings, indexing, retrieval ו־generation. זהו תיאור מוצר רשמי שמסייע להבין את השרשרת; הוא אינו מוכיח שהמסמכים שלכם חולקו נכון או שהפלט נאמן למקור.

לכל ריצה שמרו מזהה, רשימת מקורות, גרסאות, הצלחות וכשלים. קובץ אינו זמין לחיפוש רק מפני שנשלח ל־API. בתיעוד File Search של OpenAI, לדוגמה, יש לבדוק שהקובץ הגיע למצב completed; התיעוד גם מתאר ציטוטי קבצים וסינון לפי metadata. אם הקליטה חלקית, השאירו את הגרסה הקודמת פעילה או חסמו את הנושא — אל תערבבו חצי עדכון בלי סימון.

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

5. מחייבים מקור בגרסה שניתנת לפתיחה

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

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

6. בונים מבחן קבלה לשאלות ולשליפה

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

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

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

7. מעדכנים ומסירים בלי חלון אפור

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

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

דוגמה היפותטית: נוהל החזר הוצאות

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

קלט מתוכנן: הנוהל הפעיל והודעת תיקון מאושרת; המצגת מסומנת superseded; הטיוטה נשארת מחוץ למאגר הפעיל. לכל מקור מוגדרים בעלים, קהל, תוקף וגרסה. פלט מתוכנן: תשובה קצרה, סכום או כלל רק אם הופיעו במקור תקף, קישור לסעיף, גרסה ומצב answered או needs-clarification. הרשאות: כל העובדים רשאים לקרוא את הנוהל; רק התפעול מנהל גרסאות; אין למודל הרשאת כתיבה או אישור הוצאה. בדיקות: עובד רגיל, עובד ביחידה עם כלל חריג, ניסוח בעברית ובאנגלית, שאלה על השנה הבאה, קישור שבור וסתירה בין ההודעה לנוהל. תנאי עצירה: לא נמצא מקור פעיל; שני מקורות שווי מעמד סותרים; המשתמש אינו מורשה; הקובץ לא סיים קליטה; או שהתשובה מוסיפה תנאי שלא קיים במקור.

התוצאה המותרת יכולה להיות "פנו לתפעול". זו אינה ירידה באיכות כאשר אין מקור תקף; זו התנהגות צפויה שמונעת מן המודל להמציא מדיניות.

מקרי כשל ותשובה צפויה

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

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

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

מסמך תקף שלא נשלף: מסמנים כשל retrieval, בודקים חילוץ, חלוקה, metadata ושאילתה לפני שמשנים את ניסוח התשובה.

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

אין תשובה במאגר: מחזירים no-valid-source עם מסלול הסלמה; אין להשלים ידע כללי כאילו היה מדיניות ארגונית.

קישור שבור: מציגים שהמקור אינו ניתן לאימות ומעבירים לבעלים; אין להסתיר זאת מאחורי שם קובץ.

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

מגבלות

RAG או File Search אינם הופכים מקור לנכון, עדכני או מותר. חלוקה למקטעים עלולה להפריד תנאי מן החריג שלו; metadata יכול להיות שגוי; מנגנון החיפוש עלול להחמיץ מונח; והמודל עלול לנסח מסקנה שאינה נתמכת גם כאשר קיבל מקור מתאים. הרשאות במוצר אחד אינן מוכיחות הרשאות במוצר אחר.

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

מה המקורות מלמדים ומהו היישום המוצע

NIST AI 600-1 — Generative AI Profile, פורסם ב־26 ביולי 2024 ועודכן בעמוד ב־8 באפריל 2026. NIST מציג מסגרת רוחבית וולונטרית לניהול סיכוני AI לאורך מחזור החיים. פנקס המקורות ודף העבודה כאן הם יישום מוצע של המערכת, לא דרישה מצוטטת של NIST.

OpenAI API — File Search, תיעוד מוצר רשמי שנבדק ב־23 בספטמבר 2026. הוא מתאר מצב קליטה, ציטוטי קבצים, הכללת תוצאות חיפוש וסינון metadata. היכולות והדוגמאות שייכות למוצר המתועד ואינן כלל לכל מנוע חיפוש.

Microsoft Learn — Copilot data protection architecture, עודכן ב־18 באוגוסט 2026 ונבדק ב־23 בספטמבר 2026. הדף מסביר את השפעת הרשאות, תוויות רגישות, שיתוף ומדיניות מחזור חיים ב־Microsoft 365 Copilot. הוא אינו הוראת פריסה כללית לכל RAG.

Google Cloud — RAG Engine overview, תיעוד מוצר רשמי שנבדק ב־23 בספטמבר 2026. הדף מפרט את שרשרת ingestion, transformation, embeddings, indexing, retrieval ו־generation. רצף הבקרה במדריך הוא התאמה מערכתית מוצעת, לא תוצאת ניסוי של Google או AI NEWS ישראל.