סוכן המחקר של Roman ל-ZCode: מרעש קהילתי לראיות להחלטות מוצר
Roman, מנהל קהילה ב-Z.ai, מתאר את תוסף ZCode שתכנן ופיתח, עם ראיות שאפשר לעקוב אחריהן ותשובה סופית שנכתבת בידי אדם.
מבוא מערכתי
המאמר עוסק ב-Roman, מנהל קהילה ב-Z.ai, ובפרויקט ZCode Discord Research Agent שלו. המאמר בגוף ראשון שלהלן הוא תיאורו של Roman לעבודת התכנון, ההנדסה והפיתוח שלו. זהו תיאור אישי של הפרויקט, לא הודעה רשמית של Z.ai ולא טענה להזמנה, אימוץ או תמיכה מצד החברה.
המאמר של Roman בגוף ראשון
הבעיה שבחרתי לפתור
בקהילות כמו שרת Discord של Z.ai, משתמשים מספרים על צרכים דחופים הרבה לפני שכולם מזהים מגמה. קשה לזהות מגמות בזמן שהן מתהוות בתוך נפח כזה של שיחות. החלטתי לבנות פתרון טכנולוגי לבעיה הזאת.
חומר הגלם כבר היה שם, וזו בדיוק הייתה הבעיה. קהילת תמיכה יכולה להיות מלאה במידע שקשה ללמוד ממנו. אדם אחד מתאר תהליך שבור בשרשור תקלה, ואחר מדווח על אותו כשל בכותרת אחרת. פרט האבחון השימושי היחיד עשוי להימצא בצילום מסך. שיחה ארוכה מערבבת תלונות ישירות, הסכמות קצרות ושאלות אם הגיע תיקון. קריאת יותר הודעות אינה מבטיחה החלטת מוצר טובה יותר.
תכננתי ופיתחתי את ZCode Discord Research Agent כדי לצמצם את המרחק בין דברי הקהילה לבין פעולות שצוות מוצר יכול לנקוט באחריות. רציתי דרך חוזרת לחקור משוב, לשמר את הראיות וליצור דוח שמנהל תמיכה יכול לבדוק. המטרה היא מחקר שאפשר להגן על מסקנותיו, לצד חיסכון בזמן.
תהליך מחקר
בניתי את הפרויקט כתוסף מקורי לסביבת ZCode, שבמרכזו כלי Python מקומיים. התהליך מתחיל בהגדרת היקף ובאיסוף, ממשיך לניתוח ולדיווח ובמקרה המתאים לתשובה שנבדקת. רכיב האיסוף מביא הודעות שרשור ומטא-נתונים של קבצים מצורפים; הסוכן מיישם את שיטת המחקר. בונה הדוחות הופך את הניתוח המובנה למסמכי עבודה.
האיסוף צריך לשמר את מה שנאמר, הניתוח להסביר את המשמעות והדוח להציג מסקנה ואת גבולותיה. פסקה שנשמעת סבירה אינה תחליף לשרשרת הראיות הזאת.
שיקול הדעת נשאר גלוי. קיבוץ סמנטי, בדיקת צילומי מסך והבחנה בין תלונה אמיתית להערת אגב הם חלק מהתהליך המונחה בידי הסוכן. איני טוען שסקריפט Python קטן מבין אוטומטית כל שיחה.
הנדסה שמתחשבת במבנה של Discord
כלי מחקר צריך לכבד את מבנה המקור שלו. פורומים ב-Discord מכילים שרשורים ובהם השיחות החשובות. הפרויקט כולל גילוי קטגוריות וערוצים, שרשורים חדשים וארכיוניים, דפדוף בין דפי הודעות, הורדת קבצים ומניפסט איסוף מקומי. שכבת ה-API כוללת ניסיונות חוזרים לאחר מגבלות קצב ושגיאות רשת.
האיסוף מוגבל במספרי פורומים ושרשורים שנקבעים בהגדרות, וברירת המחדל היא עד 800 הודעות לשרשור. קובצי שרשורים שכבר במטמון נעקפים במקום להתרענן ברציפות. הבחירות האלה מצמצמות עבודה חוזרת ומגבילות את הטענות האפשריות: מדגם אינו מוכיח שכל השיחות נקראו, ושרשור במטמון אינו בהכרח עדכני.
הכלים פועלים מקומית בסביבת המפעיל, ללא שירות אירוח נפרד לפרטי גישה. פעולה מקומית היא בחירה ארכיטקטונית, לא הבטחה כוללת לפרטיות, לאבטחה או לאישור מצד הפלטפורמה.
זיהוי מגמות בלי להמציא ודאות
עשר הודעות אינן בהכרח עשרה משתמשים שנפגעו. אותו כותב עשוי לפרסם שוב את תלונתו, כמה תגובות רק מבקשות עדכון, ותגובה קצרה כמו 'גם אצלי' מוסרת פחות מידע מתיאור ברור של כשל.
לכן התהליך מפריד בין תלונות מובהקות לתגובות גבוליות, מוציא שאלות סטטוס מספירת התלונות וסופר עותקים של אותו טקסט מאותו כותב פעם אחת בלבד. הוא מקבץ דיווחים קשורים למשפחות בעיות ושומר את ההפניות לשרשורים. הוא גם מבקש לבדוק צילומי מסך שהורדו כאשר מזהי אבחון שימושיים חסרים בטקסט.
כך קל יותר לערער על המספרים. מנהל צריך להיות מסוגל לשאול מדוע כותב נספר, איזה שרשור תומך במסקנה ואילו ראיות חסרות. רציתי שהדוח יעמוד בשאלות האלה.
דוחות שאפשר לבדוק
שכבת הדיווח יוצרת חוברת Excel מרובת גיליונות ו-HTML מוכן להדפסה, עם יצירת PDF ישירה כשספריית ReportLab האופציונלית זמינה. החוברת מפרידה בין סיכום, שרשורים לפי משפחות בעיות, ראיות מפורטות, ביקורת תשובות ובדיקות קבצים מצורפים.
מנהל יכול להתחיל בסדרי העדיפויות, ומי שחוקר כשל מסוים יכול לחזור לראיות. אם מישהו יערער על מסקנה בחודש הבא, הנתיב לשרשורים המקוריים יישאר בדוח.
סיוע לתמיכה עם תשובה סופית של אדם
מעניין אותי במיוחד שאותו תהליך מחקר יכול גם לסייע בעבודת התמיכה עצמה.
לאחר קבלת שאלה הוא יכול לאסוף ראיות מהשרשורים, לאחזר תיעוד מבסיס ידע מקומי ולהציע פתרונות אפשריים עם המקורות שלהם. איש תמיכה שנתקל בתקלה לא מוכרת מקבל נקודת פתיחה מבוססת מחקר.
אדם כותב בכוונה את התשובה הסופית. הסוכן מציע, והאדם מחליט מה הקהילה תשמע. תהליך התשובה דורש תיעוד רשמי או תקדים שאושר בידי מנהלים, כתובות מקור מדויקות והסלמה כנה כאשר המקורות אינם עונים. הוא שולל הבטחות מומצאות לתיקונים, לתאריכים או לפיצוי. השליחה נשארת שלב נפרד שאדם מאשר מראש. רציתי להעביר את הראיות תוך שמירת שיקול הדעת והקול האנושיים.
להפוך את הכלי לשימושי לאחרים
התייחסתי גם להתקנה כחלק מהמוצר. המאגר כולל הגדרת מרקטפלייס לתוספים משלו, כך שקובץ ZIP שהורד יכול לשמש מקור התקנה. המסלול המתועד מאפשר למנהל תמיכה לבקש מ-ZCode להתקין תוסף מקומי בלי להרכיב ידנית סביבת Python.
סקריפטי הליבה משתמשים בספרייה התקנית של Python; יצירת PDF ישירה דורשת תלות אופציונלית. הקוד כולל נתיבים ל-macOS, ל-Windows ול-Linux; בדיקות חיות מתועדות כרגע רק עבור macOS, ובהן איסוף שרשורים אמיתיים, הורדת קבצים, יצירת דוחות וסבב מלא בבסיס הידע. התמיכה ב-Windows וב-Linux ממומשת, אך הערות האימות עדיין דורשות בדיקות חיות במערכות האלה.
מה נבנה ומה נשאר
זהו מימוש מוקדם עם חלקים עובדים ועבודה לא גמורה. רישומי האימות הם ראיה לבדיקות מסוימות, לא להיקף ייצור, לאימוץ או לחיסכון מדוד בזמן. כיסוי האיסוף, עדכניות המטמון, ההתנהגות במערכות שונות וכללי הפלטפורמה למחקר קהילתי אוטומטי דורשים עוד עבודה לפני פריסה רחבה. אני מעדיף לציין את הגבולות האלה.
זו עבודת ההנדסה שאני רוצה לעשות: להתחיל מבעיה תפעולית, לבחור תהליך מתאים, לבנות את הכלים ולהגביל את הטענות לראיות. הרצון להבין משתמשים טוב יותר הפך למערכת שמתרגמת משוב לסדרי עדיפויות שאפשר לבדוק.
כאשר צוות מחליט מה דורש תשומת לב, הוא צריך להיות מסוגל להראות מדוע.
הערת פרסום
Roman מתאר את יכולות הפרויקט ואת הבדיקות המתועדות; אלה אינן בדיקות מוצר שהורצו שוב באופן עצמאי. התיעוד הציבורי של ZCode מאשר את מנגנון התוספים והמרקטפלייס המקומי, לא את תוצאות הפרויקט או את עמידתו בכללי הפלטפורמה.