שאלה כללית, אתם מפתחים על גבי המכונה שלכם או על VMs. אני נוט
שאלה כללית, אתם מפתחים על גבי המכונה שלכם או על VMs. אני נוטה לVM
אנחנו סטארטאפ קטן ואני תוהה אם להתחיל ״תרבות״ אצלנו שככה עובדים.
אני חרד ממה שאנשים עושים לפעמים וקצת נמאס לי להיות שומר הסף של כל הsecrets והcredentials בחברה. ממה שאני רואה עיקר הבעיות מגיעות מהזיות של האייגנט סביב קבצים לוקלים במחשב או permissions ששכחו מחוברים
איך מתנהלים אצלכם בארגון?
איךזה פותר לך את בעיית הקרדנשלס?
חייב אחריות אישית אבל זה יותר נוח, יש לי את הסטאפ הקבוע
כל משימה גדולה מרים instance חדש
ואז אני יותר בבקרה על מה מחובר
VM פשוט נותן לך שקט נפשי לעבוד במוד של dangerous
הבעיה של הcreds אתה יכול לפתור עם קומפוננטה שיושבת בין המשתמש קצה לLLM, סטייל Gateway
בול
אני פחות רוצה להיכנס לפרטים טכניים, יש לי ממש פרוייקט קטן שמרים לי את זה כל פעם. יותר תוהה איך אתם הייתם מקבלים את זה
כי אני צופה התנגדות
זה חד משמעית חוויה פחות חלקה ונעימה, הטענה שלי שבסוף בפיתוח שהוא דיי harness driven זה כבר לא מחיר כל כך גבוהה
אני מאוד אוהב לעבוד עם Dev Containers, כי זה משהו שאתה יכול להגדיר פעם אחת ולהפיץ לכל הצוות, ואז לכולם יש בדיוק את אותה סביבה.
זה גם מאוד מקל על הפיתוח ומאפשר להריץ לוקאלית את כל המערכות, בסיסי הנתונים והדאטה בתוך הקונטיינר, בלי ללכלך את המחשב המקומי.
אבל זה לא בהכרח הפתרון הנכון לכל פרויקט. יש פרויקטים מורכבים יותר שדורשים סביבות מורכבות, ואז קשה יותר לעבוד עם Dev Containers. במצבים כאלה, אנשים מתחילים לדרוך אחד לשני על הסביבות ופוגשים אחד את השני במרג'ים.
אבל אם המערכת פשוטה, טכנית, אין על dev containers.
אתה מריץ את האייגנט בתוך הקונטיינר? איפה כל הAPI TOKENS לMCPs שלו?
בסוף אם אתה שומר על הUX אותו הדבר, או דומה (לדוגמא אתה יכול ללמד את החבר׳ה שלך לעבוד עם כלי סטייל herdr remote) להרים herder server בvm והם מתחברים אליו וזה עבודה ממש 1:1 כמו לוקאלי מול אייג׳נט שיושב בענן
אז למה שתהיה התנגדות?
הם לא אמורים להרגיש את זה
אני משתמש ואוהב dev containers השאלה שלי קשורה יותר לsupply chain attacks שיש כל שני וחמישי
צא מנקודת הנחה שבשלב כלשהו האייגנט שלך יריץ npm install על חבילה זדונית שתשתה לך את כל הסיקרטים בתוך הקונטיינר
אם יש לך hot sso session בתוך הקונטיינר הוא גם ילך לAWS וישתה לך את הסיקרטים משם, KMS / kubernetes secrets וכו
זה ממש ספציפי לנו, אבל בסוף המוצר הוא מוצר סייבר שמותקן על מכונות קצה. כדי להריץ ובאמת לראות את הפרוייקט צריך מכונה. אם זה לא מספיק גם יש לנו UI כמובן ודברים בתהליך הפיתוח שצריכים visualization. אם לא יהיה להם UI בVM הם לא ישתמשו בזה - ואני רוצה להיות כן, גם אני כנראה לא ההייתי משתמש בזה (ד״א זה למה dev containers נפל כאופציה).
מצד אחד אני מבין למה אנשים רצים בauto מצד שני אני רוצה שהם יפסיקו לעשות את זה על מכונה שלכם
שם, זה בסוף בסדר, רובם זמניים ולהשתמש בסיסמאות קבועות זה משהו שאני נגד עם container או בלי. זה לא גרוע יותר מלרוץ על המכונה אז אנחנו כבר בכיוון הנכון
ד״א אני משתמש בvirtual buddy פרוייקט חמוד שמרים vms דיי בנוחות ויש לו מלא מערכות הפעלה וכו
https://go.chatlytics.ai/r/GTtvcaq
אין לי קשר לחברה אבל אני דיי אוהב את המוצר אז אפרגן להם פה 🙃
הprovider שמספק את הtoken/מפתח צריך לתמוך בזה לא?
בהחלט אבל כל הגדולים מדברים אחד עם השני google / aws / github / gitlab
הם מתחרים שלנו (וגם האלגוריתם שלהם דומה לשלנו) אז יכול לתת קצת רקע. זה בעיקרון שוק ענק עם המון פוטנציאל ולא מספיק אנשים שיכולים לבנות את זה פנימית בארגונים בצורה נקודתית. הם בונים פלטפורמה דומה לשלנו במענה שלה שמקצרת זמני פיתוח או בונה מודלים יעודיים באופן אוטונומי לבעיות מדודות. הם קראו לאלגוריתם ליצירת דאטה שלהם RL Calibrated decisions ואנחנו במקרה קראנו לו RL for measurable decisions
הנקודה המהותית היא שיש המון ארגונים שהאופציה של בניית מודלים יעודיים לבעיות בארגון קשה לפיתוח, אז האלטרנטיבה זה להשתמש במודלים גנריים שהם יקרים ואיטיים. והכלים האלה נותנים למפתחים וארגונים את היכולת להכניס מודלים יעודיים שהם זולים ומהירים בצורה סקיילבילית
יש מישהו שבנה / ממליץ על company brain עובד ואיכותי?
מה התהליך הנכון לבצע
תודה
חברה לאו לאו טק בתחום הלוגיסטיקה עובדים על פריוריטי ככל שרלוונטי
השנקל שלי - הפרד ומשול (ביחס לסוכנים, קונטיינרים, שרתים, סקריפטים ופייפליינים, ולבסוף כמובן כמה שיותר הפרדה ושליטה בAPI/קרדס)
תוכל לתת דוגמא לבעיות כאלה? הכוונה מודלים של ml קלאסי?
זה לא ml קלאסי. זה מודלים עמוקים לכל דבר ועניין מבוססי טרנספורמרים בארכיטקטורות שונות ומספר פרמטרים שונים (תלוי משימה). אבל בעיות מדודות זה כל דבר שהאאוטפוט או התהליך יכול להיות מדיד. למשל דאטה לagent security יכול להיות מדיד ע"י הסתכלות על האם אייג'נט מותקף עשה פעולה הרסנית. או מודל של english-to-sql הוא מדוד ע"י בדיקת של האם הקוורי הוא ולידי, האם הוא בסכמה הנכונה, והאם הוא מתאים לדאטה שהיוזר ביקש באנגלית. בעיות טרנספורמציה אותו דבר. אתה יכול למדוד האם האאוטפוט הוא באמת הטרנספורמציה של האינפוט. יש גם בעיות שהם חצי מדודות. למשל PII של כרטיסי אשראי או כל תהליך extraction אחר. היכולת למדוד את איכות הדאטה אומר שהמודל שתאמן יהיה נקי מbias ורעש וככה המודל יעבוד יותר טוב, המודל יכול להיות יותר קטן (משמע יותר מהיר וזול), וזמן האימון גם קטן
העבודה תהיה בשילוב עם מודלים "רגילים"?
אם השאלה היא על איך אנחנו פותרים את הבעיה, וב"רגילים" אתה מתכוון למודלים של קלוד, צ'אט, ג'מיני וכו', אז כן. לנו יש מערך של model solver שזה מערך בעיית אופטימיזציה של איזה סוג מודל, גודל, קונסטלציה צריך בשביל בעיה מסויימת. בעיות פתוחות או בעיות מורכבות יתכנסו כצורך למודלים גדולים
טוב, אני חוזר בי. לא מדובר פה במודל ממשפחת ה-GLM. התבלבלתי בין Union Alpha ל-Oman Alpha.
Omen Alpha הוא GLM ב-99%, אבל Union Alpha הוא חיה אחרת לגמרי. בטוח סיני. הוא חושב שהוא Claude בחלק מהמקרים, אבל המודל מאוד איטי. זה לא מתאים ל-GLM לשים דבר כזה לבדיקות.
הוא איטי ברמות שהוא לא שמיש לדעתי. זו הפעם הראשונה שאני לא מצליח לעשות ג'יילברייק — לא כי המודל חכם מאוד, אלא כי הוא פשוט כל כך איטי שהוא נכנס לטיימאאוט מהשאלות שלי, אז ויתרתי, הוא ניצח אותי באיטיות