פיתוח סוכן AI עם גישה למסד נתונים

פיתוח סוכן AI עם גישה למסד נתונים

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

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

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

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

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

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

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

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

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

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

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

דרכים לחבר את הסוכן למקורות נתונים

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

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

ארבעה מצבים — ומה המחיר שלהם

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

כיצד אנו בונים את הסוכן: שלבי העבודה ההנדסית

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

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

מה אנו מוסרים ללקוח: סכימות, תפקידים, נהלים

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

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

ניתוח פרויקט: סוכן עם גישה למסד נתונים

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

צווארי בקבוק בהתחלה

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

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

תוצאת הפרויקט

זמן התגובה ירד מ-40 דקות ל-4, התפוקות הידניות הצטמצמו פי שישה, ו-86 % מהפניות נסגרות בלי אדם. 14 % הנותרים — שליפות לא שגרתיות — עוברים לאנליסט עם טיוטת שאילתה מוכנה, ולא מאפס.

במה שונה סוכן AI מאינטגרציה רגילה עם מסד נתונים?

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

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

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

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

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

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

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

שאלות טכניות נפוצות והתלבטויות

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

מה יקרה אם מבנה מסד הנתונים ישתנה?

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

אילו הרשאות ניתנות לסוכן?

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

כיצד מתמודדים עם מידע אישי?

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

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

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

נדון במשימה: מה להבהיר לפני ההתחלה

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

• מקורות נתונים ואופן הגישה: אילו מערכות, רפליקה נפרדת או מסד נתונים פעיל, הרשאות קריאה בלבד, אילו טבלאות ותצוגות מותרות.
• רשימת שאלות: 15–20 ניסוחים אמיתיים של עובדים — כך רואים איזה שיעור מהפניות שגרתי ואיזה דורש ניתוח אנושי.
• פורמט התשובה: טבלה, תמצית או גרף; השיהוי המותר; מתי הסוכן חייב לומר «אין נתונים», ולא לנחש.
• שדות רגישים: מה אסור להציג לתפקידים, האם נדרש מיסוך, הפרדת גישה ויומן שאילתות.
• נקודות כניסה: צ'אט, פורטל פנימי, מערכת פניות — וכיצד בנויה האימות בכל אחת.
• פרופיל עומס: כמה עובדים וכמה שאילתות ביום, עבודה בזמן אמת או לפי לוח זמנים.
• גבולות התשתית: קונטור סגור או ענן, דרישות מחלקת האבטחה, מי אחראי על ההרשאות.

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