ארכיטקטורת עוזר שמדברת עם נתוני החברה

רווחים:

• תכנון הרכיבים וזרימת הנתונים של עוזר RAG ארגוני מקצה לקצה
• שילוב נתונים מרובי מקורות (ויקי, כרטיס, PDF, מסד נתונים) למסייע יחיד
• קבל החלטות ארכיטקטוניות עבור מדרגיות, שמירה במטמון והשהייה

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

רכיבים מקצה לקצה

עוזר RAG ארגוני מורכב משני קווים נפרדים. שורת האינדקס (לא מקוון) מכינה את הנתונים; שורת השאילתה (מקוונת) עונה על השאלה.

רכיבי קו אינדקס:

1. מחברים: מחברים ששולפים נתונים ממקורות - ויקי, מערכת כרטיסים, חנות קבצים, מסד נתונים, דואר אלקטרוני.
2. נורמליזציה: המרת פורמטים שונים (PDF, HTML, DOCX) לטקסט נקי; ניקוי כותרת עליונה/תחתונה.
3. Chunking + Metadata: Chunking ותיוג (מקור, תאריך, סמכות).
4. הטמעה + טעינה: כתיבת וקטורים ומטא נתונים במסד הנתונים הווקטוריים.

רכיבי צינור שאילתה:

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

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

הדמיית זרימת נתונים

[אינדקס - לא מקוון]משאבים ← נרמל ← Chunk+Metadata ← הטמע ← וקטור DB (ויקי, כרטיס, PDF, DB)[שאילתה - מקוונת]שאלת משתמש ← עיבוד מקדים ← אחזור (היברידית+פילטר+דירוג מחדש) ← הנחיה (הקשר+שאלה+הוראה) ←+ דגם →

שילוב נתונים מרובי מקורות

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

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

מקור

סוג תוכן

אמון

תדירות עדכון

מדיניות PDF

כלל רשמי

גבוה

מדי חודש

מאמר עזרה

נוהל

בינוני-גבוה

מדי שבוע

היסטוריית כרטיסים

מדגם אמיתי

בינוני

מתמשך

ויקי

תו מעורב/נוכחי

משתנה

מתמשך

מדרגיות, מטמון והשהייה

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

כלל אצבע בצד העלות: הצעד היקר ביותר הוא בדרך כלל מספר האסימונים שעוברים לדגם הגדול יותר. לכן, צמצום ההקשר ל-4 חלקים טובים על ידי דירוג מחדש משפר גם את האיכות וגם את העלות. עיצוב נפוץ הוא להשתמש במודל קטן/מהיר יותר לסיווג או ניתוב פשוטים, ובמודל חזק יותר עבור התשובה הסופית (למשל claude-opus-4-8).

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

אדריכלות חלשה / אדריכלות חזקה

חלש (תסריט בודד, הכל מעורב):

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

רב עוצמה (צינורות מפוצלים + מטא נתונים + מטמון + סטרימינג):

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

שלושה מיני מארזים

מקרה 1 - קו מבולבל, עיכוב כבד. סטארט-אפ כתב סקריפט שמעבד מחדש קובצי PDF עם כל שאלה; כל תשובה ארכה בממוצע 11 שניות. כאשר שורת האינדקס הופרדו והנתונים הועברו קודם לכן למאגר הווקטורים, זמן השאילתה ירד ל-1.3 שניות ועם הסטרימינג, "המילה הראשונה" הופיעה ב-400 אלפיות השנייה.

מקרה 2 - יותר מדי משאבים, סדר עדיפויות שגוי. עוזר תמיכה נתן משקל שווה ל-PDF של המדיניות ולהערות כרטיס ישנות; המודל הציג לעתים דירוג שגוי של עובד מלפני שנתיים ככלל הרשמי. כאשר נוספו להנחיה מטא-נתונים של source_tour וההוראה "שקול מדיניות רשמית במקרה של התנגשות", שגיאות בעדיפות שגויה צומצמו ב-89%.

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

טעויות נפוצות

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

לסיכום

• עוזר RAG הארגוני מורכב משתי שורות נפרדות: אינדקס לא מקוון ושאילתה מקוונת; להפריד ביניהם פיזית.
• יצירת אינדקס = מחבר + מנרמל + נתח/מטא נתונים + הטמעה/העלאה; query = טרום תהליך + אחזור + הנחיה + יצירה + לאחר תהליך.
• נתונים מרובי מקורות משולבים למאגר יחיד, אך מטא-נתונים מסוג source_type וקדימות אמון נשמרים.
• סטרימינג ומטמון עבור זמן השהייה, החמצת הקשר ובחירת דגם עבור עלות הם קריטיים.
• ללא הוספה מחדש לאינדקס, המדד הופך מיושן; עבד מחדש מסמכים משתנים באופן קבוע.

משימת יישום

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

רשימת בדיקה

• [ ] אני יכול לצייר את שורות האינדקס והשאילתה בנפרד ועם הרכיבים הנכונים.
• [ ] אני יכול לשלב נתונים מרובי מקורות עם source_type ו-trust priority.
• [ ] אני יכול לקבל החלטות סטרימינג/מטמון עבור חביון ובחירת דגם עבור עלות.
• [ ] אני יודע מדוע אסטרטגיית הוספה מחדש לאינדקס היא חיונית.
• [ ] אני זוכר שהשלב היקר ביותר בארכיטקטורה שלי הוא בדרך כלל האסימון שהולך לדגם הגדול יותר.