עוד מישהו חווה בעיות חיבור עם קודקס או שזה רק אני?
עוד מישהו חווה בעיות חיבור עם קודקס או שזה רק אני?
גן,
היו לו כמה בעיות היום לאורך הבוקר
מי שעדיין לא הפעיל את
/plugin enable cc-plugin-you-should-know@builtin
תעשו לעצמכם טובה ותעשו את זה. אני יודע - אני תקליט שבור וכו', אבל כמות הזמן שהאיג'נט הצדדי הזה חוסך. וכמות הפאקים שהוא תופס שהיו עוברים טסטינג בסבבה היא גדולה מאוד.
מעניין מה האג'נדה שלו. מרגיש שזה מהלך על איך לא לצרוך את השירות של המודלים ישירות מהייצרנים.
מה לדוגמא?
תחשוב שיש לך סיניור שיושב ומנתח דברים מהצד ומוצא מלא דברים שיכולים להיות בעייתים, שלעיתים קרובות האיג'נט המרכזי לא רואה או יודע ומדלג
והוא לא מייצר מלא רעש? אתה צריך לעשות משהו כדי שהmain agent יקרא את זה?
הוא לא מייצר רעש כמעט בכלל. אם אין לו משהו טוב לומר, הוא שקט. מתוך חמישים פידבקים שהוא נתן, אולי 2 ידעתי כבר ולכן דילגתי. וקל מאוד להעביר את זה לאיג'נט הראשי.
כן, צריך לפתוח את הדוח על ידי כתיבת הספרה 1, ואז בשביל לשלוח לאיגנ'ט צריך ללחוץ 2
איך זה מבחינת צריכת טוקנים?
אתה מפעיל אותו מקלוד קוד או מהארנס אחר?
קלוד קןד, לא שמתי לב לצריכה מוגברת. זה די לייט על משאבים
האמת שאני פשוט כבר די חם על קצב מילוי הקונטקסט בקלוד קוד אז אני קצת חושש מלהוסיף לו עוד דברים שיגבירו את קצב וניפוח הקונטקסט שלו אבל אני אבדוק את זה
הוא לא לוקח מהקונטקסט הראשי. האיג'נט הראשי לא רואה כלום, זה כמו ה /btw
להבנתי.
זה מאוד משתנה מה אתה עושה, לאחרונה גיליתי שאני למשל לא מבצע מספיק compact לסשנים, מה שהפך את צורך העבודה שלי למאוד בזבזנית אם הבנתי נכון
גם ברמת משאבים מהמכונה עצמה, פעולות של מידול ורינדור מפרקות חבילה, גם וידאו של 10-20ד
כן ולא. כן כי זה גובה יותר טוקנים ככל שהקונטקסט יותר מלא. לא בגלל שאחרי קןמפקטינג, לא בהכרח תקבל מודע שיודע כל פרט חשוב.
אז יהיה בזבוז טוקנים להביא אותו למקום הנכון. כמובן שיש דרכים לשפר וכו. אבל בבסיס זה המצב.
הרגשת פעם שאחרי קומפקט הוא לא הצליח להמשיך בידיוק מאותה נק והיו דברים שהוא זייף לאחר מכן?
אני דיי בטוח, חמרות שעוד לא הוכחתי, Claude code + Opus 5.X בהשוואה נגיד לopencode + GLM 5.3 הוא חזיר קונטקסט, ולא באחוזים בודדים.
עוד לא בודדתי אם זה המודל או ההארנס. בהתחלה חשבתי שזה ההארנס, אבל לאחרונה אני כבר לא בטוח אם זה לא המודל.
בפעם הבאה שישארו לי טוקנים לפני הריסט השבועי, אולי אני אעשה ניסוי מבוקר.
ברור, וככל שהעבודה יותר מדוייקת ונשענת על ניואנסים ככה יותר קשה לזה ואתה צריך שיהיה סיכום מלא ומדוייק מהסשן לפני כיווץ
מתי אתה מפעיל את הקומפקט?
לרוב אני מנצל את הסשן עד תומו - לעיתים מתחיל את ההכנות בחמש האחוז האחרונים
מה זה עד תומו? 850 אלף טוקנים.
עד אפס קונטקסט
זה מה איג'נט הראשי אחרי הפידבק מהמשני:
מה הכוונה? אתה נותן לו להגיע ל- auto conpact ברירת מחדל שלו?
תעבור לפרטי, נדבר שם
דווקא דיון מעניין 😊
יש לי שיחות עם 10 פעמים קומפקט שעובדות מעולה.
עם איזה מודל באיזה נקודה?
ASTRA / OPUS
אולי הן היו יכולות להיות יותר יעילות יותר מושלמות אבל זה מייצר לי רעש מיותר
כל עוד הן יעילות בשבילי - היכולת לעבוד על משהו במשך כמה ימים בלי לתחזק אותו כל הזמן יותר חשוב לי מיעילות שלא נדרשת
אם באמת יש איזו בעיה סופר קשה מחקרית שצריכים MAX REASONING וכו
או שבאמת רואים שנכנסים ללופים, שווה לעשות HANDOFF ולתת וכו...
אני גם שואל אותו הרבה פעמים, את אופוס - להמשיך פה או שיחה חדשה - הוא יודע טוב להחליט
אני מסכים. אחרי שראיתי שבקודקס זה עובד טוב גם מבחינת איכות וגם מבחינת עלות לעבוד עם חלונות של ~270K , שיניתי לקלוד את הנקודה של האוטו קומפקט. שם באזור ה-300 פלוס מינוס.
נראה לי אחד השינויים היותר טובים שעשיתי לאחרונה. מספיק הרבה יותר.
אני לא נוגע, הם יודעים יותר טוב ממני
אני לא מסכים אם זה. זה קצת כמו גידול ילדים. יש את מה שידוע ויש את מה שאתה יודע. ולמערכת יש אינטרסים שהם לאו דווקא אלינד עם שלך. בסוף אתה זה שמשלם את הטוקנים, ו-cache miss הוא דיי כואב באזורים האלה.
כל השיחות שלי עברו מאות או אלפי קומפקטים
כל הלקוחות שלנו חיים על שיחות של אלפי קומפקטים
נדמה שכי גדול שראיתי היה כמעט 10k או משהו
יש דברים שגם 200k לא מזיז.
בסשנים של פיתוח, אני יכול להגיד בבירור שאחרי כמה קומפקים (מעריך מעל 10 כי לא מדדתי)
הוא מתחיל להיות טיפש ברמות, גם ב %10 קונטקסט.
זה מורגש בהתנהגות שהוא מתחיל לעשות דברים שהם ברור הגיעו מקונטקסט מזוהם בחלקי עובדות.
זה משתנה כל מודל וכל עדכון תוכנה, בסופו של דבר כל הקסטומיזציה הזו יכולה להפריע.
אם המודל יודע ובנוי לקונטקסט של 1M, אתה מקצר לו סתם
דרך אגב כל הקסטומיזציה שלנו הולכת למות בכל מקרה, גם ההארנס, הכל עובר למודל..
כל זה שאנחנו כרגע חכמים יותר מה"לא מפתחים" הולך להעלם לגמרי. כבר די נעלם.
לא עדין למפתחים יש פרקטיקה ושפה שאין ללא מפתחים
כן, זמנית
מקווה שאתה צודק :)
זה יקל על החיים שלי
זוכר איך ישבנו והגדרנו HOOKS ולופים וכל מני וירטואוזיות שנתנו לנו לעבוד טוב יותר עם קלוד קוד ?
עכשיו לא צריך כלום. אפס. פתח 5.5 וזהו.
מה זה הלקוחות שלכם, ובמה המודל הגודל של החלון שהם עובדים איתו?
אני מניח שיש לך ניהול זכרון נוסף שהסשן יושב עליו, לא?
בדכ שמגיע ל50%+
שהדהים אותי שהם שקלו ביחד מעל 54gb , אחרי שביצעתי , הרבה אוויר השתחרר למכונה ואפשר לה להתקדם במשימות
קונטקסט ארוך אוחז בזכרון, מה שמגביל עבודה במקביל
לפחות במה שהתנסתי, אולי לחברים פה חוויה שונה
זה כמו שתגיד שהאוטו שלך בנוי לנסוע 240 כי זה שמופיע לו בדשבורד.
ברור לך שגם הוא יכול לנסוע ולהגיע למהירות הזו, זו לא המהירות שמשיגה ביצועים אופטימלים.
בגדול, אני יכול להביע מלא דוגמאות בהן יש הבדל בין ביצועים מקסימליים לביצועים אופטימליים.
אתה יכול להסתכל גם על הבנצ׳מרקים שהם עושים, שאפילו בסביבות סטרליות מראות לך שיש מחיר להגדלה של המיצוי של החלון.
גם אצלי, אופוס 5.5 , בניית מוצר עם 3d ורינדורים
לקוחות הגודל בינוני+, לא fortune 500 אבל גם לא המכולת של סמי. קאסטום לכל שיחה, בדרך כלל המקסימום של המודל, אפשרות פופלרית נוספת היא 500k איפה שיש עליה במחירים. יש זכרון בנוסף לקומפקט כן, אבל הקומפקט משאיר אחריו עד 30 אלף טוקנים כולל הזנב שמאחורי הקומפקט
טרם הפעלתי אוטומטי, אתה מרוצה?
מריח כמו ערבוב מודלים
סליחה. התכוונתי, מה השירות שאתם נותנים, או מה זה המוצר שרץ ועושה קומפט 10 אלף פעם? אתם מריצים אותם על מודלים של אופוס עם 1M קונטקסט ואוטו קומפקט דיפולטי?
סשן אחד, מודל אחד
לי זה עובד טוב יחד עם קומפקט, לפעמים מבצע פורק ונותן למודל אחר לבדוק או להבין
אייג׳נטים בשלל טעמים ותהליכים אייג׳נטיים
לא זה לא אותו הדבר
זה כמו להגיד שיש לי 128 RAM
תשתמש רק ב32
עודף היעילות הזו בסופו של דבר רק מכניס רעש וחוסר יעילות בעיני
ולאופוס 5.6 תצטרך לכוונן את זה או שאולי תפגע בביצועים
אם אתה יודע יותר טוב מהם איך המודל עובד הכי טוב אז אתה אמור גם ללמד את המודל...
מאוד. אני אנסה לאסוף קצת עובדות כדי שזה לא יהיה רק תחושות.
אני מסכים איתך, כל מי שלא מבין את זה פשוט לא מספיק bitter lesson pilled
כל חודש הכל ניהיה טוב יותר
אתה רק צריך לאפטם פאנדמנטלס
מסכים, הכל מתחיל בבסיס ברור פשוט ומובן
ואז כל מודל חדש משפר את העוגנים האלו
נכון גם ככה כולם יסיימו בוריאנט כזה או אחר של pi :)
פשוט כי אין הרנס שהוא יותר bitter lessoned ממנו, תבנה תוספים כדי לתת את החלקים שהם ספציפיים לדומיין ולא צריך הרבה מעבר לזה
אני לא מסכים לגבי ההשוואה לראם. ככל שהקונטקסט של המודל יותר מזובל, לא רק בגודל אלא גם בתוכן, ככה הוא פחות טוב.
בהתחשב בזה שחלקים לא מבוטלים ממה שאנטרופיק מפתחים מגיע מזה שזה קודם פותח בחוץ ואז הם ממסדים את זה האמירה הזו הולכת רחוק. אתה יכול להגיד שמה שיש זה מספיק טוב, ושלא משתלם לך להשקיע בלאפטם את הסביבה או את הכלים. זו אמירה לגטימית. לא מסכים עם זה שהם יודעים ״הכי טוב״ מה טוב לי 🙂
אני לא חושב שהם יודעים מה הכי טוב לך, אני חושב שאתה נאלץ להתמודד עם מה שהם מכתיבים לך כי אם האופטימיזציות שלך לא בדיסטריביושן של המודל אז אתה פשוט מקבל ממנו פחות, יש התנהגויות של הרנסים בינהם גם משפטים טפשיים בפרומפטים שדוחפים את המודל למקומות ספציפיים. כשאנטרופיק מאמנים את המודלים שלהם הם מאמנים אותם בתוך claude code בשלבים של הrl, אין לך ברירה להתיישר ולהתאים את עצמך למה שהם מכתיבים כל עוד את חי על המודלים שלהם
יש נקודות אמצע בין אנטרופיק לopenai, אפשר לחיות בין 2 הגישות שלהם בדיוק מתי שאתה מפסיק לאפטם כל דבר שהוא לא פאנדמנטלי
יש הבדל בין מזובל לבין אחרי קומפקט
אני לא חווה בכלל מצב מזובל יותר
ובחוויה שלי כמה שעוזבים את אופוס ואסטרה לנפשם בלי להתערב הם עובדים הכי טוב
עד כאן מסכים. אבל יש לך מרחב פעולה. חלק ממנו הוא גם לאפטם את הטוקנים שאתה משלם עליהם.
תן לי את ההיפוטזה שלך ללמה אתה חושב שאם אני עוצר משימות, סתם לדוגמא ב-500K ועושה handoff, או מתכנן מראש כך שמשימות הן כאלה שלא מתקרבות לחלון הקשר הזה, אז אני עובד נגד מה שאנטרופיק תכננו?
500k זו נקודה טובה לעצור בה, זה מספיק למרבית המשימות. ונראה לי ששאר הדברים שכתבת זה סתם איך שאתה עובד עם הכלים האלו, כולם עובדים אחרת
שים לב אגב שאסטרה, בהנחה שאתה לא צורך דרך ה-API הוא לא 1M. זה בבסיס הטענה שלי.
אני עדיין יוצא לי מלא לראות שהכיוון לא נכון, לנקות ולהתחיל חדש. מביא תוצאות הרבה יותר טובות מלנסות לתקן את הכיוון
אני לא מתכנן שום דבר אני מדבר על המודל וסוגר את המשימה באותה שיחה, אבל כשיש ריפאקטור מאוד גדול אז לפעמים אי אפשר בלי plan כלשהו
נכון, ואני לא נוגע בו, הם החליטו שזה הכי יעיל בשימוש בקודקס, זהו
אופוס החליטו ש1M, עובד לי
מסכים. סתם נתתי 500k כדוגמא
בעיני זה בזבוז זמן כל הטכנאות הזו, תמיד היתה
נפלתי אליה כמו כולם בהתחלה, עכשיו היא ממש מיותרת למעט אם אתה עובד על איזו תשתית באיזורים האלו
מה בעצם אתה מגדיר טכנאות?
סקילים זה טכנאות?
או רק דברים מכניים של ההרנס
אני לא עושה כלום, אין סקילים אין כלום. אבל זה מגה חשוב מה יש בקונטקסט…
נגיד דבאופס, אם ההסטוריה של השיחה מזובלת, אי אפשר לסמוך על המודל שיעשה דברים נכון בקוברנטיס
אולי. בניתי לא מזמן פרוייקט עם קימי. יש להם במנוי היקר את האופציה של ה-1M. העובדה הפשוטה שכשנתתי לו לעבוד בלי להתערב לו, נגמרה לי המכסה של החודש בתוך פחות משבוע.... חזרתי לעבוד עם המוד המוגבל של K3 ל-270 או משהו כזה, וזה היה שינוי כל כך קיצוני שפתאום נכנס אוויר למערכת. אי אפשר היה שלא לשים לב להבדל.
שחף חשוב מה יש בsystem message וכמה הטולים ארגונימיים לאייג׳נט, כל שאר האמצע לפעמים לא מורגש גם ב700k
אבל זה חדש במודלים האחרונים
גם באחרונים. עדיין מרגיש את זה
פשוט הרבה יותר טוב כשהקונטקסט נכון
לא יודע אני נותן לרוץ עד מיליון, אבל כולם ממש עובדים בדרך שלהם עם הכלים האלו אין תשובה נכונה
חסכנות היא לא דוקא יעילות. תשאל את המפתחים של קימי שעובדים ללא הגבלת טוקנים מה עדיף. זה שלא נגמר לך זה סבבה, מי אמר שזה יותר טוב למודל? נקודה למחשבה
אני חושב שזה ממש תלוי במשימה, במורכבות המערכת, באופי הפיתוח.
מהניסיון שלי עבודה ישירות עם הארנס כזה או אחר לא מצליחה לייצר תוצאה ברמה שאני רוצה והרבה פעמים מבלי הכיוונונים שקיימים בתוך הוורקפלואו שאני עובד איתו ומשפר כל הזמן זה פשוט לא אותו דבר…
אתה נהיית גרופי של אופוס 5.5? תמיד היתה לך חולשה לדריו
מה שכן, אני ממש מסכים עם המשפט הזה
נתנו לנו חיה רעה, כל אחד לומד להשתלט עליה בדרכו
די כבר עם הTAB החדש כבר אנחנו בעיקר מכונת TABS
כמעט תמיד ההצעות TAB שלהם עובדות
כל מה שנשאר זה להיות מומחה בדומיין שאתה מפתח
אני חושב שהיום יש עדיין יתרון מובהק לאנשים שיודעים לכתוב תוכנה לסקייל
ושוב זה תלוי על מה עובדים..
אין ספק שלא בכל מקום צריך את המומחיות הזאת לקצה
אני חושב שבשביל להגדיר יעילות אתה צריך משהו שעובד כאילוץ. אז למי שאין מגבלת טוקנים, אתה יכול להגיד שזמן זה אילוץ. כל עוד אין לי אניסוף טוקנים, אז האילוץ הזה הוא יותר דומיננטי עבורי מאשר הזמן. אגב, גם בר אתגור, כי ככל שהסשן ארוך יותר, זמני התגובה מתארכים, ואני עדיין טוען, שאתה נמצא ב-dumb zone של המודל. באופן יחסי כמובן.
אבל זה שיקול אחר בכלל
זה כמו להגיד אני מוכן לעבוד פחות טוב כדי לחסוך כסף
זה בסדר לגיטימי, רק לא בטוח שזה יותר טוב למודל. זה הכל.. מה גם שזה משתנה כאמור כל גרסת מודל גרסת הארנס וכו.. מרדף אבוד
להיות מומחה בלקחת את הכלים האלה לקצה ולדעת לאתגר אותם לא פחות חשוב
אל תשכח שכאן בקבוצה כנראה נמצאים הטופ אנשים שיודעים לעבוד עם הכלים האלה
רוב האנשים ממש לא במקום הזה
עוד נקודה פילוסופית
אנחנו סומכים על המודל כבר לחלוטין
אף אחד פה לא קורא קוד, למעט קריפטו נקודות קריטיות
יש לי מערכת DEPLOY שבחלומות שלי הייתי מסוגל לכתוב אותה
צוות DEVOPS שלם היה צריך
אז לא לסמוך עליו שידע לעשות קומפקט יעיל?
למה דוקא שם החוסר אמון? לא יודע.
כן אני מדבר על המרחב הזה כמובן. אם אתה מומחה במשהו בתוכנה זה כבר כמעט לא רלוונטי אם אני לא מומחה בו אבל מגיע מאותו המרחב
מסכים מאוד
הגבולות מאוד הטשטשו
אני חייב להגיד שאני מריץ במקביל את אופוס לעשות fact checks, וספוילר גם הוא הולך להגיד שלהגיע לגבול החלון זה לא אופטמלי. ביקשתי ממנו רגע לסכם את לתוך html ואני אשתף.
בלי קשר, חייב להגיד, שהיה דיון ממש מעניין 🙂 ❤️
יום אחד @144646630064147 או @107684007252205 יצליחו לארגן מיטאפ
אני תקוע על "להציק לתומר על Reactor" מיוני. זה "מחר בבוקר" הכי ארוך בהיסטוריה 😅
אם מישהו סוגר מקום ותאריך, אני לוקח על עצמי את המרצים ואת ה-RSVP. ואם AntAgent מגיע ראשון, לפחות ניהנה מתחרות בריאה 🤖
בינתיים סכם לי על מה היה כל הדיון היום בין עדי, נועם, מיכאל ושות'?
🔍 הדיון היום: למלא את חלון ה-1M או לשמור על קונטקסט קצר?
• תומר: לטענתו Claude Code עם Opus שורף הרבה יותר קונטקסט מ-OpenCode עם GLM. מבחינתו מקסימום זה לא אופטימום, כמו אוטו שמגיע ל-240 אבל לא בנוי לנסוע ככה. כשעבד עם קימי ב-1M המכסה החודשית נגמרה לו בפחות משבוע. כשעבר למצב המוגבל "נכנס אוויר", ולדבריו בסשן ארוך אתה ממילא ב-dumb zone.
• מיכאל ואיתמר: נותנים לסשן לרוץ עד הסוף, ומיכאל עם מאות ואלפי קומפקטים. מיכאל לא מרגיש ירידה גם ב-700K, ולדעתו מה שקובע זה ה-system message וכמה הכלים נוחים לסוכן.
• שחף ושי: לא מסכימים. קונטקסט מזובל בתוכן פוגע, לא רק בגודל. שי טוען שאחרי בערך 10 קומפקטים המודל מטמטם גם כשרק 10% מהחלון בשימוש. שחף נותן דוגמה: בדבאופס ובקוברנטיס אי אפשר לסמוך על סשן מלוכלך.
• עדי: חיסכון זה לא יעילות. אם המודל בנוי ל-1M, קיצוץ סתם מגביל אותו. בעיניו כל ה"טכנאות" של כיוונון ההארנס היא מרדף אבוד שמשתנה עם כל גרסה. ובפילוסופיה: אנחנו כבר סומכים על המודל בכל הקוד, אז למה לא לסמוך עליו גם בקומפקט?
• נועם: לדעתו זה תלוי במשימה. הוורקפלואו המכוונן שלו עדיין עושה הבדל, ומי שיודע לכתוב לסקייל ולקחת את הכלים לקצה עדיין מחזיק יתרון.
✅ השורה התחתונה: אין הכרעה. כולם הסכימו עם מיכאל ש"כל אחד מאלף את החיה בדרך שלו". תומר מכין סיכום HTML מ-fact check שהריץ עם Opus, וכבר עשה ספוילר: גם Opus אומר שלהגיע לקצה החלון זה לא אופטימלי 😄
יופי הוא הבין את החלק הכי חשוב
אני לא מגיע ל-50% קונטקסט כמעט לעולם
חחח מה זה
וסשנים עם עשרות קומפקטים בתוך הסשן
עכשיו תעדכן על סמך עובדות😂
@144646630064147
חחח נראה שנפלט לי “NO” בלי הקשר 😅 לא וטו על המיטאפ.
🔍 עדכון על סמך הדוח של תומר
• תומר ושחף צדקו: Opus 5.5 תומך ב-1M, אבל אף מקור לא אומר שהוא עובד הכי טוב שם. בבדיקת GraphWalks הוא מקבל 90.6 עד 128K, ובטווח 256K–1M הוא יורד ל-66.8. זו נפילה של 24 נקודות, וגם אנתרופיק עצמה מזהירה מ-"context rot".
• מיכאל: לפי הנתונים "לא מורגש גם ב-700K" לא מחזיק. אבל זה בנצ'מרק של שליפת מידע, לא עבודת קוד אמיתית.
• לעדי יש נקודה חלקית: גם קומפקט מאבד מידע, בעיקר נתיבי קבצים ו-endpoints. לכן הנקודה הטובה היא באמצע, לא "אף פעם" ולא "כל הזמן".
• שי: אף אחד לא מדד כמה איכות הולכת לאיבוד אחרי הרבה קומפקטים. הטענה שלו לא הופרכה וגם לא הוכחה.
• עלות: כל עוד ה-cache חם, קונטקסט גדול זול. אחרי הפסקה ה-cache מתקרר, וכל תור עולה פי 25 בערך.
✅ השורה התחתונה: הדוח ממליץ על auto-compact בסביבות 300K, ובעבודה שדורשת דיוק אפילו 200–250K. אבישי, עם פחות מ-50% ועשרות קומפקטים אתה בדיוק באזור המומלץ. השאלה הפתוחה היחידה היא כמה עולים כל הקומפקטים האלה.
⚠️ המספרים של Opus 5.5 מגיעים מדיווחים משניים על טבלה של גוגל, ולא מאנתרופיק.
(responded in 33s)
זה קורה לאייג׳נטים שעושים round robin על 4 מודלים שונים בתשובה אחת
אני מקמפקט באזור ה-40%
בטח עברת בטעות אצל gemini
ארבעה מודלים בשביל שתי אותיות — לפחות על ה־N היה קונצנזוס 😅
אנט מצחיק
אצלי לא. פשוט הדוח הכי עדכני שבדק את זה היה של גוגל.
לא אני צוחק עם ant יש לו אחלה חוש הומור
לא. זה בדיוק קורה לאייגנטים עם יותר מדי קונטקסט 🙈
יש לכם מושג מה אנתרופיק עושים ב compact?
מבחינתי מספיק שיהיה
Summarize session
+
מה שאופוס ענה באיטרציה האחרונה, ואפשר לפתוח עם זה סשן חדש.
אם יותר לי, אני רוצה רגע להציג שאלה בכיוון אחר. נגיד מונוריפו גדול, שהרבה עובדים איתו. בהנחה שטוקנים עולים במחיר api ולכן יקרים. יש איזה פריימוורקים שמנסים לאפטם את זה שלא כל סשן של כל משתמש מגיע לכל מיני מסקנות ביניים או תהליכי ביניים שחוזרים על עצמם ושהיו יכולים להיחסך?
שואל בשביל חבר😝
Code is truth
מסכים עם מיכאל + מה שהקוד לא אומר נכתב בפרויקטים שאני עובד בהם בצורה של ADRs כאשר יש קשרים בין הADRs וגם לאיזה מודולים הם קשורים.
נוצר אינדקס שעוזר לנווט לADRs הרלוונטים בהתאם לסשנים הבאים, זה מאוד עוזר מהניסיון שלי
חייב לומר שאני מסיים את כל הקונטקסט ואני לא רואה בעיות עם פיבל או אופוס 5.5. לאחרונה חזרתי לפיבל 5.1 על מקס. אז אולי זו הסיבה שזה פחות מורגש בקונטקסט שהתמלא כמעט עד סופו. אבל עם אופוס 5, 4.8, ו 4.6 - זה היה מורגש מאוד.
זה דווקא מסתדר עם הדוח, איתמר. GraphWalks בודק שליפת מידע מתוך הקונטקסט, לא עבודת קוד. בקוד, רוב מה שמצטבר בחלון הוא פלטי כלים ישנים שהמודל ממילא לא צריך לחזור אליהם.
הפער שאתה מרגיש בין 4.6–5 לבין 5.5 ו-Fable מתאים לכך שכל דור מחזיק יותר טוב בקונטקסט ארוך. וב-max המודל כנראה מוציא יותר חשיבה על מציאת מה שרלוונטי, מה שמקזז חלק מה-context rot. אז "לא אופטימלי" כבר לא אומר "שבור", לפחות בדור הנוכחי 😄
לא היתה ברירה.... מתסבר שחיזוי מדוייק של רעידות אדמה - גם לאופוס 5.5 קשה.
באמת שאני מאוהב באופוס 5.5, הוא מעולה לכל כך הרבה דברים.
נכנסתי לקרוא עליכם לא מזמן, נשמע מטורף הלוואי ותצליחו
אבל בכל מה שקשור אצלי בעבודה המורכבת, בנקודות החשובות הוא לא מצליח לראות את התמונה המלאה - ופיבל 5.1 מצליח.
אבל זו נקודה נכונה. בדרך כלל אנחנו מודדים טיב, אם חזרה התשובה הנכונה. לא תמיד שמים לב כמה טוקנים זה עלה כעדות לכמה אפורט הושקע💡
כן יש להם איזה magic sauce מיוחד ומעצבן
בדיוק. בנצ'מרקים בודקים אם התשובה נכונה, ופחות שואלים כמה עלה להגיע אליה. אם Fable על max מגיע לתשובה הנכונה ב-900K אחרי שהוציא פי 3 טוקני חשיבה, יכול להיות שהמודל לא עמיד יותר ל-context rot. אולי פשוט משלמים יותר כדי לפצות עליו.
המדד המעניין הוא כמה טוקנים לוקח לפתור משימה נכונה, ב-200K מול 900K. אם המספר עולה ככל שהחלון מתמלא, אז ה-rot עדיין שם, רק שעכשיו הוא מופיע בחשבון ולא באיכות 💸