רובוטריקים: 50% מהר יותר? למה המתחרים שלך נכנסים לפאניקה עכשיו!

עסקים רבים בודקים כלים מבוססי שנאים לחיפוש, תמיכת לקוחות, סקירת מסמכים וזרימות עבודה של תוכן. העלאת מהירות של 50% נשמעת שימושית, אבל המהירות לבדה לא פותרת כל בעיה עסקית. מודל מהיר יותר עשוי להפחית את זמן התגובה, לתמוך ביותר משתמשים או להשתמש במחשוב נמוך יותר. זה עשוי גם ליצור שאלות חדשות: - האם המערכת הנוכחית שלך יכולה להתמודד עם יותר בקשות? - האם תגובות מהירות יותר ישמרו על אותה רמת דיוק? - האם הנתונים שלך מוכנים לשימוש רחב יותר במודל? - האם הצוות שלך יכול למדוד את התוצאה העסקית? ראיתי חברות מתמקדות במהירות המודל תוך התעלמות מהשלבים סביב הדגם. התוצאה היא לעתים קרובות תהליך מהיר יותר עם אותם עיכובים בגישה לנתונים, אישור או מסירת לקוחות. ## מה המשמעות של "50% מהר יותר"? המספר צריך הקשר. מודל עשוי להשלים משימה תוך 2 שניות במקום 4 שניות במסגרת הגדרת בדיקה ספציפית. התוצאה יכולה להשתנות עם: - אורך קלט - אורך פלט - חומרה - גודל אצווה - גרסת דגם - תנאי רשת - בדיקות אבטחה - זמן תגובה של מסד נתונים שיפור מהירות המוצג ב-benchmark טכני עשוי לא ליצור את אותו רווח במערכת עסקית חיה. אם בקשת תמיכת לקוחות מבלה את רוב זמנה בהמתנה לשאילתת מסד נתונים, שנאי מהיר יותר ישפר רק חלק מהתהליך. אני מתייחס לנתון של 50% כנקודת התחלה לבדיקה, לא כתוצאה עסקית מובטחת. ## שלב 1: מצא את החלק האיטי של זרימת העבודה שלך עקוב אחר המסע המלא של בקשה. לעוזר תמיכה, מדדו: 1. זמן קבלת הודעת הלקוח 2. זמן לאחזור מידע על החברה 3. זמן שימוש בדגם 4. זמן בדיקה של התשובה 5. זמן הדרוש לאישור הצוות 6. זמן שליחת התשובה תצוגה זו חושפת לעתים קרובות פער שימושי בין מהירות הדגם למהירות המערכת. חברה קמעונאית עשויה לגלות שהמודל שלה יוצר תשובה תוך שלוש שניות, אבל למאגר המוצרים לוקח שמונה שניות להחזיר מידע על מלאי. החלפת המודל עשויה לעזור, אך שיפור חיבור מסד הנתונים עשוי לייצר רווח גדול יותר. ## שלב 2: בחר משימה שבה המהירות חשובה לא כל מקרה שימוש צריך מודל מהיר יותר. עיכוב של שנייה אחת או שתיים עשוי להיות לא משנה כאשר צוות כספים סוקר דוח ארוך פעם ביום. זה עשוי להשפיע רבות כאשר אלפי קונים שואלים שאלות במהלך תקופת מכירות עמוסה. ל-Sped יש ערך עסקי ברור יותר בתחומים כגון: - תמיכת לקוחות חיה - חיפוש בתוך אוספי מסמכים גדולים - תורי סקירת הונאה - סיוע במוקד טלפוני - המלצות למוצרים - זרימות עבודה של תרגום - כלי ידע פנימיים אני מעדיף לחבר מהירות עם תוצאה מדידה. תוצאה זו עשויה להיות זמן המתנה קצר יותר, יותר בקשות המטופלות על ידי אותו צוות, או שימוש נמוך יותר בתשתית. ## שלב 3: בדיקת דיוק לצד מהירות תשובה מהירה יותר אינה מועילה אם העובדים צריכים לתקן אותה. צור ערכת מבחנים המשקפת עבודה עסקית רגילה. כלול שאלות קצרות, מסמכים ארוכים, בקשות לא ברורות, מידע חסר ומקרים הדורשים סירוב בטוח. מעקב: - זמן תגובה - דיוק תשובות - שיעור שגיאות - זמן תיקון אנושי - עלות לכל בקשה - שביעות רצון המשתמש - שיעור כשלים בתקופות עמוסות צוות תמיכה עשוי להשוות בין שני מודלים בין 500 שאלות קודמות של לקוחות. דגם אחד עשוי להגיב מהר יותר, בעוד שהשני עשוי להפיק פחות פרטי מוצר שגויים. הבחירה הטובה יותר תלויה בעלות של כל שגיאה ובערך של כל שניה שנחסכה. ## שלב 4: בדוק את בקרות הנתונים והאבטחה שלך מערכת מהירה יותר יכולה לעבד מידע נוסף, ולכן בקרות הנתונים צריכות לעמוד בקצב. סקירה: - מי יכול לשלוח בקשות - לאילו נתונים המודל יכול לגשת - כמה זמן מאוחסנים הנחיות ותשובות - האם מידע אישי מוסר - איך צוות סוקר פלטים רגישים - מה קורה כשהמערכת נכשלת חברה שמשתמשת בכלי AI עבור מסמכי עובדים לא צריכה להניח שעיבוד מהיר יותר הופך את המערכת למוכנה לגישה רחבה יותר. כללי הרשאה, רישומי ביקורת וביקורת אנושית ברורה עדיין חשובים. ## שלב 5: הפעל פיילוט לעסקים קטנים פיילוט מוגבל נותן לצוות שלך ראיות שימושיות מבלי לשנות כל זרימת עבודה בבת אחת. בחר מחלקה אחת ומשימה אחת. הגדר תקופת בדיקה ברורה. השווה את התהליך הנוכחי עם המודל המהיר יותר בתנאים דומים. לדוגמה, חברת לוגיסטיקה יכולה לבדוק עוזר שמסכם תעודות משלוח. הצוות יכול להשוות: - זמן סיכום ממוצע - זמן עריכה ידנית - פרטי משלוח שהוחמצו - מספר הערות שטופלו לכל עובד - משוב מצוות השיגור הפיילוט צריך לכלול תקופות עמוסות ומקרים קשים. מערכת שעובדת היטב עם עשר בקשות עשויה להתנהג אחרת עם כמה מאות. ## שלב 6: הכן אנשים לשינוי מהירות הדגם יכולה לשנות את קצב העבודה. הצוות עשוי לקבל טיוטות אוטומטיות יותר, התראות או בקשות לקוחות. ללא כללים ברורים, הנפח הנוסף יכול ליצור לחץ ולא שירות טוב יותר. ספר לעובדים: - באילו משימות הכלי יכול להתמודד - באילו החלטות צריך אישור אנושי - כיצד לדווח על תשובה שגויה - מתי לא להשתמש בכלי - כיצד יימדדו ביצועים ההשקפה שלי היא פשוטה: מודל מהיר יותר צריך לתמוך באנשים, לא להסיר את היכולת שלהם לבדוק החלטות חשובות. ## האם העסק שלך מוכן? ייתכן שהעסק שלך מוכן לבדוק דגמי שנאים מהירים יותר כאשר יש לך: - מקרה שימוש מוגדר - קו בסיס ידוע למהירות ואיכות - גישה לנתונים מתאימים - בקרות פרטיות ואבטחה ברורות - תהליך לבדיקה אנושית - דרך למדוד עלות וערך עסקי - צוות שיכול להגיב לשגיאות אם חלקים אלה חסרים, ייתכן שהשלב הבא לא יהיה שדרוג מודל. זה עשוי להיות נתונים טובים יותר, זרימת עבודה נקייה יותר או תהליך ניטור חזק יותר. טענת המהירות של 50% יכולה לפתוח שיחה מועילה, אבל השאלה האמיתית היא מעשית יותר: האם העסק שלך יכול להפוך פלט מודל מהיר יותר לשירות טוב יותר, עומס עבודה נמוך יותר או תהליך חלק יותר מבלי להפחית את האמון? התשובה הזו מגיעה מטייס מדוד, לא ממספר ההשוואה בלבד.

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

צוותים רבים שומעים שבינה מלאכותית יכולה להפוך את העבודה למהירה ב-50% ותוהים מה זה אומר בפעולות היומיומיות. ההבטחה נשמעת פשוטה: פחות זמן מושקע בחיפוש, ניסוח, קידוד ומיון מידע. האתגר האמיתי אינו גישה לכלי מהיר יותר. זה לדעת היכן מהירות עוזרת, היכן סקירה אנושית נותרה הכרחית, וכיצד למדוד את התוצאה מבלי ליצור שגיאות חדשות. אני רואה במהירות AI כשאלה של זרימת עבודה, לא כמירוץ. טיוטה מהירה יותר לא תמיד יוצרת עבודה טובה יותר. תשובה מהירה המבוססת על נתונים חלשים יכולה להוביל ליותר בדיקות, ליותר תיקונים ולפחות אמון מצד הלקוחות. ### כאשר עשוי להופיע עלייה במהירות של 50% בינה מלאכותית יכולה לצמצם את הזמן הדרוש למשימות העוקבות אחר דפוס ברור: - הפיכת הערות פגישה לנקודות פעולה - יצירת גרסה מוקדמת של תיאור מוצר - קיבוץ שאלות לקוחות לפי נושא - כתיבת פונקציות קוד פשוטות - השוואת מספר מסמכים - הכנת מתווה מחקר - שכתוב טקסט טכני באנגלית פשוטה, אבל המשימות הראשונות עדיין יגיעו לגרסה אנושית בקרוב. מחקר שפורסם של GitHub Copilot משנת 2022 מצא שמפתחים השלימו משימת קידוד מבוקרת במהירות של כ-55.8% מהר יותר בעת השימוש בכלי. התוצאה לא אומרת שכל מפתח יעבוד במהירות הזו בכל יום. המבחן התמקד בסוג אחד של משימה, עם תנאים ברורים. זה כן מראה כמה זמן AI יכול לחסוך כאשר העבודה מובנית והמשתמש יודע מה לשאול. ### בעיית הלקוחות שמאחורי ההבטחה לעתים קרובות אני רואה את אותו הלחץ על פני צוותי שיווק, תמיכה ותפעול. אנשים מבלים שעות באיסוף מידע לפני שהם יכולים להתחיל במשימה הדורשת שיפוט. סוכן תמיכה עשוי לחפש במספר מערכות לפני שיענה לשאלה נפוצה. משווק עשוי לבלות בוקר במיון פרטי המוצר לפני כתיבת עמוד שימושי אחד. מפתח עשוי לחזור על עבודת קוד דומה בכמה פרויקטים. AI יכול להפחית את זמן ההכנה הזה. זה נותן לאנשים יותר מקום להחלטות, שיחות עם לקוחות ובדיקות איכות. הרווח תלוי בתהליך סביב הכלי. צוות עם קבצים לא ברורים, הוראות חלשות וללא תהליך סקירה עשוי להרוויח מעט ממודל מהיר יותר. ### דרך מעשית לבדיקת מהירות בינה מלאכותית התחל עם משימה אחת שחוזרת על עצמה. בחר עבודה שמתרחשת לעתים קרובות ויש לה תוצאה ברורה. טיוטות דוא"ל של לקוחות, סיכומים של נתוני מוצרים והמרת הערות פגישה הם מקומות שימושיים להתחיל. רשום את התהליך הנוכחי: - כמה זמן נמשכת המשימה? - כמה אנשים משתתפים? - איפה קורים עיכובים? - באיזו תדירות טעויות דורשות שכתוב? - באילו בדיקות איכות כבר נעשה שימוש? הפעל את אותה משימה עם AI. שמור על תקן הקלט, הפלט ושיטת הסקירה דומים ככל האפשר. השוואה הוגנת צריכה יותר משעון עצר. מדוד ארבעה תחומים: - זמן חסך - שיעור שגיאות - זמן סקירה - שביעות רצון המשתמש או הלקוח משימה שלוקחת חמש דקות פחות אך יוצרת עשר דקות של תיקון אינה מהירה יותר בפועל. ### תן לכלי חומר עבודה ברור AI פועל טוב יותר כאשר הקלט מכיל פרטים שימושיים. בקשה קצרה כגון "כתוב תשובה ללקוח זה" עשויה להניב תשובה כללית. בקשה ברורה יותר יכולה לכלול: - שאלת הלקוח - המדיניות המאושרת של החברה - הטון הרצוי - אורך התשובה - מידע שאסור לסוכן להבטיח - בקשה לסימון פרטים חסרים גישה זו מסייעת למשתמש לבדוק את הפלט בפחות מאמץ. זה גם מקטין את הסיכוי לתביעות לא נתמכות. אני מעדיף הנחיות שמבקשות מהמערכת להראות אי ודאות. לדוגמה: "השתמש רק במידע שסופק. אם התשובה אינה נתמכת, סמן את הפרטים החסרים במקום לנחש." ההוראה הקטנה הזו יכולה להגן על הדיוק. ### שמור על אנשים אחראים להחלטות רגישות AI לא צריך לקבל החלטות לא מסומנות לגבי החזרים כספיים, בעיות רפואיות, תעסוקה, אשראי, עניינים משפטיים או נתונים אישיים. אדם מיומן צריך לבדוק את הפלט וליישם את כללי החברה. הצוותים צריכים גם לשקול פרטיות. אין להזין שמות לקוחות, מספרי חשבונות, הודעות פרטיות וקבצים פנימיים לכלי מבלי לבדוק את הגדרות הנתונים ומדיניות החברה שלו. למהירות יש ערך רק כאשר האמון נשאר ללא פגע. ### בניית לולאת סקירה פשוטה זרימת עבודה שימושית יכולה לפעול לפי הדפוס הזה: 1. אדם מגדיר את המשימה ומספק מידע מאושר. 2. AI יוצר טיוטה, סיווג או השוואה. 3. אדם בודק עובדות, טון, פרטיות ומגבלות מדיניות. 4. התוצאה המאושרת נכנסת לתהליך העסקי הרגיל. 5. הצוות רושם שגיאות ומתאים את ההנחיות. לולאה זו הופכת את השיפור לגלוי. זה גם מונע טעות קטנה להתפשט על פני מאות תשובות של לקוחות. ### מה עשוי להשתנות עבור העובדים משימה מהירה ב-50% לא תמיד אומרת שנדרשים פחות אנשים. המשמעות עשויה להיות שאותו צוות יכול להתמודד עם יותר בקשות, לבלות יותר זמן עם לקוחות או להפחית עבודה חוזרת. קופירייטר עשוי להשתמש בבינה מלאכותית לקיבוץ נושאים וטיוטות מוקדמות, ואז להתמקד בקול המותג ובדוגמאות שימושיות. מפתח עשוי להשקיע פחות זמן בקוד שגרתי ויותר זמן בבדיקת עיצוב המערכת. סוכן תמיכה עשוי לעבור מחיפוש אחר תשובות להסבר ברור. הערך נובע מהנעת המאמץ האנושי לעבר עבודה הדורשת הקשר, אמפתיה ושיפוט. לא הייתי מודד הצלחה בינה מלאכותית לפי מהירות בלבד. הייתי שואל האם הצוות מייצר שירות טוב יותר עם פחות טעויות שניתן להימנע מהן. תהליך מהיר המוריד את אמון הלקוחות אינו תוצאה חזקה. לזרימת עבודה מדודה שחוסכת זמן תוך שמירה על אחריות על אנשים יש סיכוי טוב יותר להחזיק מעמד.

צוותים רבים מוסיפים עוד GPUs כאשר דגם Transformer מרגיש איטי. זה יכול להעלות את הצעת החוק מבלי לתקן את הבעיה האמיתית. ההשהיה עשויה לנבוע מרצפי קלט ארוכים, אצווה לקויה, עבודה חוזרת ונשנית של ערך מפתח, תנועת נתונים איטית או מודל גדול יותר ממה שהמשימה דורשת. ראיתי את הדפוס הזה במערכות יצירת טקסט. המודל פועל היטב במחברת בדיקה, ואז זמן התגובה גדל כאשר מספר משתמשים שולחים בקשות בבת אחת. התשובה היא לא תמיד מכונה גדולה יותר. תוכנית מהירות טובה יותר מתחילה במדידה. ## שלב 1: מדוד את נתיב הבקשה המלא שאחריו אני עוקב יותר מזמן ההסקה הגולמי של המודל. משתמש ממתין לאסימונים, תור, ביצוע מודל, פענוח והעברת רשת. מדדים שימושיים כוללים: - זמן עד האסימון הראשון - אסימונים שנוצרו בשנייה - זמן תגובה כולל - ספירת אסימוני קלט - ספירת אסימוני פלט - שימוש בזיכרון GPU - גודל אצווה - זמן תור - בקשות מטופלות לדקה בדיקה פשוטה יכולה לחשוף את הבעיה: אורך קלט טקסט: 512 אסימונים אורך פלט: 128 אסימונים זמן מוצא: 128 מ"ר זמן תגובה: 0 מ'. לאחר מכן אני חוזר על הבדיקה עם 2, 4 ו-8 בקשות באצווה אחת. אם התפוקה עולה בזמן שזמן התגובה נשאר מקובל, אצווה עשויה להציע את הרווח הטוב ביותר. אם כל בקשה נעשית איטית, לחץ זיכרון או העברת נתונים עשויים להגביל את הביצועים. ממוצע בודד יכול להסתיר תוצאות חלשות. אני גם בודק את זמן האחזור של האחוזון ה-90 וה-95, מכיוון שלעתים קרובות משתמשים מבחינים בבקשות האיטיות יותר מהממוצע. ## שלב 2: צמצם אסימונים מיותרים תשומת הלב של השנאים הופכת יקרה יותר ככל שהקלט גדל. הנחיות ארוכות יכולות להכיל הוראות חוזרות, היסטוריית צ'אט ישנה, ​​שדות שאינם בשימוש ומסמכים גדולים שמוסיפים ערך מועט. אני סוקר את ההנחיה לפני שינוי הדגם. הנחייה קצרה יותר יכולה לשפר את המהירות מבלי לשנות את ערימת ההגשה. שינויים מעשיים כוללים: - הסרת הוראות מערכת חוזרות ונשנות - שמור רק היסטוריית צ'אט רלוונטית - הגבלת מסמכים שאוחזרו - פיצול קבצים גדולים למקטעים קטנים יותר - אחסן הוראות יציבות בפורמט שניתן לשימוש חוזר - הגדר מגבלה ברורה של אסימון פלט - הימנע משליחת מטא נתונים שאינם בשימוש למודל ייתכן שבוט תמיכת לקוחות לא יצטרך את השיחה המלאה מלפני שישה חודשים. סיכום קצר יכול להחליף הודעות ישנות רבות. המודל מקבל פחות טקסט, והמשתמש מקבל תגובה עם פחות המתנה. בדיקת האיכות חשובה כאן. אני משווה תשובות לפני ואחרי הפחתה מהירה. ספירת אסימונים נמוכה יותר שימושית רק כאשר הפלט עדיין עומד בדרישות המשימה. ## שלב 3: השתמש בשיטת תשומת הלב הנכונה תשומת לב היא לעתים קרובות המקור העיקרי לעלות בדגמי רובוטריקים. תשומת לב רגילה יכולה להשתמש בכמות גדולה של זיכרון, במיוחד עם כניסות ארוכות. FlashAttention יכול להפחית את תנועת הזיכרון על ידי ארגון חישובי קשב בצורה יעילה יותר. זה לא משנה את מטרת הדגם, אבל זה עשוי לדרוש GPU תואם, גרסת תוכנה וסוג נתונים. אני בודק את זה עם אותו הדבר: - נקודת ביקורת דגם - אורך קלט - אורך פלט - גודל אצווה - GPU - תהליך חימום השוואה הוגנת מונעת תוצאות שגויות. קרנל חדש עשוי להיראות מהיר בבדיקה קצרה ולהציג ביצועים גרועים עם הנחיות ארוכות או אצווה גדולה. תשומת לב מדפדפת יכולה לעזור במהלך יצירת טקסט. הוא מנהל זיכרון מטמון של ערך מפתח בבלוקים קטנים יותר, וזה שימושי כאשר בקשות רבות בעלות אורכים שונים. זה יכול להפחית מבוזבז זיכרון GPU ולאפשר לשרת להתמודד עם רצפים פעילים יותר. ## שלב 4: שפר את השימוש במטמון מפתח-ערך במהלך היצירה, המודל יכול לעשות שימוש חוזר במצבי מפתח וערכים מאסימונים קודמים. ללא מטמון, הוא חוזר על עבודה עבור כל אסימון חדש. אני בודק אם מסגרת ההגשה מאפשרת קבץ קבצים במטמון. אני גם עוקב אחר כמה זיכרון המטמון צורך. שיחות ארוכות וגדלי אצווה גדולים יכולים למלא את ה-GPU במהירות. מספר הגדרות משפיעות על התוצאה: - אורך ההקשר המרבי - המספר המרבי של רצפים פעילים - מדיניות תזמון אצווה - סוג הנתונים של המטמון - שיתוף הנחיה - עדיפות בקשה אורך הקשר מרבי נמוך יותר יכול להגן על הזיכרון, אך הוא עלול לחתוך מידע שימושי. קבעתי את הגבול מצרכי המשתמש שנצפו במקום לבחור מספר גדול כברירת מחדל. ## שלב 5: בדיקת קוונטיזציה עם בדיקות איכות קוונטיזציה משתמשת בפורמטים מספריים קטנים יותר, כגון INT8 או INT4, כדי להפחית את השימוש בזיכרון ולהאיץ את החישוב בחומרה נתמכת. זה יכול להיות מועיל כאשר הדגם אינו מתאים בנוחות לזיכרון GPU. זה עשוי גם לאפשר גודל אצווה גדול יותר. התוצאה תלויה במודל, במשימה, בחומרה ובשיטת הכימות. אני לא שופט קוונטיזציה לפי מהירות בלבד. אני בודק: - דיוק תשובות - אמינות כלי-התקשרות - תוצאות סיווג - קצב הזיות - עקביות תגובה - שימוש בזיכרון - מהירות יצירת אסימונים עבור כלי תיאור מוצר, שינוי איכות קטן עשוי להיות מקובל. עבור חילוץ מסמכים או יצירת קוד, אותו שינוי עלול ליצור שגיאות יקרות. ערכת מבחנים מעשית צריכה להכיל בקשות נפוצות, תשומות ארוכות, תשומות קצרות, דוגמאות קשות ומקרי קצה. אני שומר את המודל המקורי כהתייחסות במהלך ההערכה. ## שלב 6: בחר דגם קטן יותר כאשר המשימה מאפשרת זאת דגם גדול לא תמיד נחוץ למשימה צרה. דגם קטן יותר יכול להתמודד עם זיהוי כוונות, תוויות סנטימנט, ניתוב וחילוץ פשוט עם זמן אחזור נמוך יותר. לעתים קרובות אני מפריד את זרימת העבודה לשני נתיבים: טקסט בקשה פשוטה ← דגם קטן בקשה מורכבת ← דגם גדול יותר נתב קל משקל יכול לשלוח שאלות בסיסיות לדגם הקטן יותר ולשמור את המודל הגדול יותר למשימות הדורשות חשיבה מעמיקה יותר או הקשר ארוך יותר. עיצוב זה יכול להפחית את העלות הממוצעת ואת זמן התגובה. כלל הניתוב מצריך בדיקה, שכן החלטה גרועה בהתחלה יכולה לשלוח בקשה קשה לדגם שלא יכול להתמודד איתה. זיקוק ידע הוא אפשרות נוספת. מודל קטן יותר לומד מהתפוקות של מודל גדול יותר, ואז מטפל במשימה ממוקדת עם פחות פרמטרים. מקרה השימוש הטוב ביותר הוא משימה יציבה עם ערכת הערכה ברורה. ## שלב 7: הידור והגשת המודל בצורה נכונה מודל עלול לאבד מהירות כאשר נתיב ההגשה מוסיף המרות מיותרות או העברות מכשירים. אני בודק אם הטנסורים נעים בין המעבד ל-GPU במהלך ההסקה. אפילו העברות קטנות יכולות להוסיף עיכוב על פני שכבות רבות. הגשה של כלים כגון ONNX Runtime, TensorRT, vLLM או ספריות ספקים מיוחדות עשויה לשפר את הביצועים. הבחירה הנכונה תלויה בארכיטקטורת הדגם ובחומרה. אני שומר על הגדרת ההגשה עקבית במהלך המדדים: - אותו דיוק - אורכי רצף זהים - אותו מקבילות - אותו אסימון - אותה ספירת חימום - אותה מגבלת תפוקה יש למדוד את זמן ההתחלה הקרה בנפרד מהמסק החם. שרת שמתחיל באיטיות עדיין עשוי לתפקד היטב לאחר הטעינה, בעוד שהפעלה מהירה אינה מבטיחה תפוקה מתמשכת טובה. ## שלב 8: כוונן אצווה לפי צורכי המשתמש אצווה גדולה לעתים קרובות משפרת את השימוש בחומרה. הם יכולים גם להגדיל את ההמתנה לבקשה שתגיע לבד. אצווה רציפה שימושית עבור עומסי עבודה, מכיוון שהשרת יכול להוסיף בקשות חדשות בזמן שבקשות אחרות עדיין מייצרות אסימונים. לעתים קרובות זה מעשי יותר מאשר לחכות למילוי אצווה קבועה. אני מגדיר חלון אצווה קצר ומשווה: - זמן לאסימון הראשון - זמן תגובה כולל - אסימונים לשנייה - ניצול GPU - עיכוב בתור עבור עוזר אינטראקטיבי, אצווה קטנה עשויה להרגיש טוב יותר. עבור עיבוד מסמכים לא מקוון, אצווה גדולה יותר עשויה לייצר יותר עבודה בשעה. ההגדרה הטובה ביותר תלויה במוצר, לא רק בתרשים ה-GPU. ## שלב 9: בניית אמת מידה שניתן לחזור עליה. אני שומר בנצ'מרק קטן בבקרת גרסאות. הוא כולל הנחיות קבועות, מספר אורכי קלט, מספר רמות במקביל ובדיקות האיכות העיקריות. כל שינוי דגם או מנה מקבל את אותה מבחן. אני רושם: טקסט גרסת דגם חומרה Precision Batch הגדרות קלט אסימוני פלט P50 חביון P95 חביון תפוקה ציון איכות זה מונע תביעת מהירות המבוססת על בדיקה חיובית. זה גם מקל על מציאת רגרסיות לאחר שדרוג ספרייה או שינוי מיד. ההשקפה שלי פשוטה: מהירות שנאי נובעת מפינוי פסולת לפני קניית חומרה נוספת. קלט קצר יותר, שימוש טוב יותר במטמון, גרעיני תשומת לב מתאימות, אצווה זהירה ומודלים בגודל משימה יכולים לעבוד יחד. שיפור קטן בכל שכבה מייצר לרוב חווית משתמש טובה יותר מאשר שינוי אחד גדול שנעשה ללא מדידה. התצורה המהירה ביותר אינה שימושית אם התשובות הופכות לא אמינות. אני שומר על חביון, עלות ואיכות פלט באותה בדיקה, ואז בוחר את ההגדרה שמתאימה למשתמשים בפועל של המוצר.

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

עסקים רבים משתמשים בבינה מלאכותית כדי לייצר יותר תוכן. זה לבד לא יוצר יתרון מתמשך. כשאני סוקר דפים של מתחרים, אני מוצא לעתים קרובות דפוס אחר. הם משתמשים בבינה מלאכותית כדי ללמוד את כוונת החיפוש, לארגן שאלות של לקוחות, לשפר חלקים חלשים ולהדריך כותבים אנושיים. הכלי הוא רק חלק אחד בתהליך. הסוד השימושי הוא זרימת העבודה מאחוריו. פעם חשבתי שפרסום יותר דפים יביא יותר תנועה אורגנית. גישה זו יצרה ספריית תוכן גדולה, אך דפים רבים זכו לתשומת לב מועטה. כמה מאמרים ענו על נושאים רחבים מבלי להתייחס לשאלות ששאלו הקונים לפני קבלת החלטה. תהליך טוב יותר מתחיל אצל הלקוח. ## 1. מצא את השאלות מאחורי מילת המפתח מילת מפתח יכולה להראות מה אנשים מקלידים. זה לא תמיד מראה למה הם מחפשים. לדוגמה, מישהו שמחפש "תוכנת שיווק בדואר אלקטרוני" עשוי לרצות להשוות תכונות, להבין תמחור, לבדוק אינטגרציות או למצוא כלי לצוות קטן. מאמר אחד לא יכול לשרת היטב כל מטרה. אני משתמש בבינה מלאכותית כדי לקבץ חיפושים קשורים לפי כוונה: - לימוד על נושא - השוואה בין אפשרויות שונות - בדיקת תכונות המוצר - פתרון בעיה ספציפית - מחפש שירות או ספק ואז אני סוקר את התוצאות בעצמי. דפי חיפוש, דיונים בפורומים, סקירות מוצרים ורשומות תמיכת לקוחות חושפים לעתים קרובות פרטים שכלי מילות מפתח מפספס. דף הופך שימושי יותר כאשר הוא עונה על הסיבה מאחורי החיפוש, לא רק על ביטוי החיפוש. ## 2. השתמש בבינה מלאכותית כדי לחקור פערים במתחרים מחקר מתחרים אינו אמור להעתיק ניסוח של חברה אחרת. אני מבקש מבינה מלאכותית להשוות מספר דפים ולזהות: - שאלות שהם עונים - שאלות שהם משאירים בחוץ - דוגמאות שהם משתמשים בהם - טענות שצריכות ראיות - סעיפים שמרגישים כלליים מדי - מידע שעלול להיות מיושן דוגמה פשוטה מגיעה מחברת תוכנה קטנה שמכרה כלים להזמנת פגישות. המתחרים שלה כתבו על "תזמון מקוון", אבל כמה דפים הסבירו כיצד לטפל בביטולים, זמינות צוות או התנגשויות לוח שנה. החברה בנתה מדריך סביב בעיות מעשיות אלו. הדף לא הסתמך על מילות מפתח חוזרות. זה נתן לקוראים שלבים ברורים, דוגמאות ומגבלות. זה עזר לעסק למשוך מבקרים שיש להם סיבה חזקה יותר לחקור את המוצר. AI עזר לחשוף את הפער. הצוות העסקי סיפק את החוויה. ## 3. בניית מתווה תוכן ברור לפני ניסוח בינה מלאכותית יכולה להפיק מאמר מלא תוך שניות, אבל טיוטה מהירה היא לא תמיד טיוטה שימושית. אני יוצר מתווה שמשקף את דרכו של הקורא: 1. הבעיה שהקורא מנסה לפתור 2. הסיבה שהבעיה קורית 3. האפשרויות הזמינות 4. השלבים לבחירת אפשרות 5. טעויות נפוצות 6. דוגמה מעשית 7. שלב הבא ברור מבנה זה נותן למאמר כיוון. זה גם מצמצם קטעים שחוזרים על אותה נקודה עם מילים שונות. עבור תוכן מונחה מוצר, אני שומר את הודעת המכירה מחוברת לבעיה. קורא שמחפש עזרה עם שגיאות מלאי לא צריך סיפור ארוך של החברה לפני שהוא רואה פתרון. הם צריכים להבין את הסיבה, את השיטות הזמינות ואת הנקודה שבה תוכנה עשויה לעזור. ## 4. תן חומר מקור ספציפי ל-AI פלט AI משתפר כאשר אני מספק קלט שימושי. אני עשוי לכלול: - הערות לראיונות לקוח - שאלות לשיחות מכירה - כרטיסי תמיכה - תיעוד מוצר - תשובות לסקר - דוגמאות משתמש אנונימיות - פרטים על קהל היעד חומר זה נותן לטיוטה קול שהנחיות כלליות אינן יכולות לספק. צוות שיווק השתמש פעם בכרטיסי תמיכה כדי לשפר מאמר על גיבוי נתונים בענן. הדף המקורי הסביר את תכונות הגיבוי במונחים רחבים. רישומי התמיכה הראו שלקוחות מודאגים בעיקר מזמן השחזור, התנגשויות גרסאות קבצים והרשאות גישה. המאמר המתוקן ענה ישירות על החששות הללו. זה נעשה שימושי יותר מכיוון שהצוות השתמש בשפת הלקוח במקום להסתמך על טקסט כללי של AI. ## 5. שמור על ביקורת אנושית בתהליך AI יכול לארגן מידע ולהציע ניסוח. זה עדיין עלול ליצור טענות לא נתמכות, להחמיץ הקשר או להציג פרטים ישנים כעדכניים. אני סוקר כל הצהרה עובדתית שמשפיעה על החלטת קנייה. מגבלות מוצרים, מחירים, אינטגרציות, אזורי שירות, דרישות טכניות ונתוני ביצועים זקוקים למקור או הסבר ברור. אני גם מסיר טענות כמו: - "עובד לכל עסק" - "הפתרון היחיד שאתה צריך" - "תוצאות מובטחות" - "הבחירה הטובה ביותר לכולם" גבולות ברורים בונים יותר אמון מאשר הבטחות רחבות. עמוד יכול להסביר מי עשוי להרוויח ממוצר, מי לא, ואיזו הכנה צריך הקונה. סגנון זה תומך באיכות החיפוש ונותן לקוראים בסיס הוגן להחלטה. ## 6. שפר את הדף לאחר שאנשים משתמשים בו פרסום אינו סוף העבודה. אני בודק שאילתות חיפוש, מעורבות בדף, משוב מלקוחות והמרות. דף עשוי לקבל ביקורים מחיפושים שלא היו חלק מהתוכנית המקורית. שאילתות אלה יכולות להראות את מה שהקוראים עדיין רוצים לדעת. דף עשוי לדרג גם עבור נושא שימושי אך לא יצליח ליצור פעולה. זה יכול להצביע על הסבר חלש, דוגמה חסרה, ניווט לא ברור או אי התאמה בין המאמר להצעה. אני מעדכן את הדף על סמך האותות האלה במקום להוסיף טקסט ללא סיבה. ## יתרון הבינה המלאכותית היתרון הוא לא לייצר מספר גדול יותר של מאמרים. זה לומד מהר יותר, שואל שאלות טובות יותר והופך את הידע של הלקוחות לתוכן מועיל. אני משתמש בבינה מלאכותית לתמיכה במחקר, קיבוץ נושאים, רעיונות מתאר, בדיקות עריכה ומציאת דפוסים. אני שומר על שיפוטיות, ראיות, קול מותג והבנת לקוחות עם אנשים. האיזון הזה נותן לעסק תהליך תוכן חזק יותר. המתחרים עשויים להשתמש באותם כלים, אך הם עשויים שלא להשתמש באותם תקני תובנות או סקירה של לקוחות. הפער נובע מהעבודה מאחורי ההנחיה. צור איתנו קשר עוד היום כדי ללמוד עוד איימי וו: amy.wu@ihuagroup.com/WhatsApp +8613612662976.

פנג, סידה; Kalliamvakou, איריני; ציהון, פיטר; Demirer, Mert — 2022 — ההשפעה של AI על פרודוקטיביות מפתחים: עדות מ-GitHub Copilot Vaswani, Ashish; שזיר, נועם; פארמר, ניקי; אושקורייט, יעקב; ג'ונס, ליאון; גומז, איידן נ; קייזר, לוקאש; Polosukhin, Ilia - 2017 - Attention Is All You Need Dao, Tri; פו, דנקי; ארמון, סטפנו; רודרה, אטרי; Ré, Christopher - 2022 - FlashAttention: תשומת לב מדויקת מהירה וחסכונית בזיכרון עם IO-Awareness Kwon, Woosuk; לי, ג'והאן; ג'ואנג, סיאנג; שנג, יינג; ז'נג, ליאנמין; יו, קודי; גונזלס, יוסף; ג'אנג, האו; Stoica, Ion — 2023 — ניהול זיכרון יעיל למודל שפה גדול המשרת עם PagedAttention המכון הלאומי לתקנים וטכנולוגיה — 2023 — מסגרת ניהול סיכונים של בינה מלאכותית AI RMF 1.0 Bommasani, Rishi; הדסון, דרו א; עדלי, אהסן; אלטמן, ראס; ערורה, סימרן; פון ארקס, סידני; ברנשטיין, מייקל ס; בוהג, ג'נט; בוסלוט, אנטואן; ברונסקיל, אמה; et al — 2021 — על ההזדמנויות והסיכונים של מודלים של בסיס