Чому бенчмарки запуску не дадуть відповіді на ваше питання
Кожен новітній реліз приходить із графіком, що показує його перевагу в наборі стандартизованих оцінок. Ці цифри реальні, але майже марні для рішення, що вам використовувати в понеділок, з трьох причин.
Відрив невеликий, а завдання не ваші. Різниця у два бали на бенчмарку міркувань нічого не каже про те, чи пише одна модель кращий лист клієнту, чи надійніше тримає схему на двохстах рядках.
Бенчмарки вимірюють завдання, які легко оцінити. Речі з правильною відповіддю. Більшість професійної роботи такої не має: тон, структура, рішення про те, що прибрати. Саме тут моделі відрізняються найбільше і саме тут нічого не вимірюють.
Порівняння при запуску робить сам постачальник. Не обов'язково нечесно, але ніхто не публікує оцінку, де їхня модель посіла друге місце.
Питання, яке варте відповіді, вужче: на конкретних завданнях, які ви виконуєте двадцять разів на тиждень, яка з двох моделей краща? Опублікованої відповіді на це немає, і з'ясувати це можна приблизно за годину.
Що насправді зазвичай змінюється між релізами
У нещодавніх новітніх релізах покращення, що мають значення у щоденному використанні, постійно стосуються тих самих сфер, і вони рідко потрапляють в анонс.
| Що покращилося | Як ви це помічаєте | Чи показує це бенчмарк |
|---|---|---|
| Дотримання інструкцій | Модель перестає ігнорувати третю умову | Рідко |
| Негативні інструкції | «Не використовуй аналогії» справді виконується | Ні |
| Пригадування довгого контексту | Знаходить потрібне на 140 сторінці, а не лише на 3 | Частково |
| Дисципліна форматування | У таблиці завжди ті колонки, які ви просили | Ні |
| Калібрована невпевненість | Каже, що не знає, замість вигадувати | Ні |
| Контроль тону | Менше переписувань перед тим, як текст можна надіслати | Ні |
| Глибина міркувань | Помічає граничний випадок, який ви пропустили | Так, саме це і вимірюють |
П'ять із цих семи не видно на графіку бенчмарку, і саме тому нова модель відчувається кращою або гіршою в роботі. Дотримання інструкцій, зокрема, це різниця між першим чернетковим варіантом, який ви редагуєте, і тим, який викидаєте.
Годинна оцінка
Робіть це замість того, щоб читати огляди запуску. Запустіть обидві моделі поруч на власному матеріалі.
- Зберіть п'ять реальних завдань за останні два тижні. Справжніх, із вашим фактичним контекстом, а не іграшкових запитів. Включіть щонайменше одне завдання на написання тексту, одне на структурований вивід і одне, де потрібні були міркування про щось незнайоме.
- Запишіть, що має містити хороша відповідь для кожного, одним реченням, перш ніж щось запускати. Цей крок не дає вам віддавати перевагу тій відповіді, яка довша і впевненіша, а це сильне і здебільшого несвідоме упередження.
- Запустіть кожне завдання на обох моделях паралельно, щоб жодна відповідь не була прив'язана до іншої.
- Оцінюйте за обсягом редагування, тобто скільки роботи між результатом і тим, що ви б надіслали. Не за тим, як це звучить.
- Відзначайте розмір розриву, а не лише переможця. Взаємозамінні результати кажуть вам припинити думати про вибір моделі для цього завдання, і це справді корисно.
- Ведіть журнал. Через три місяці, коли вийде наступний реліз, ви повторите ті самі п'ять завдань і отримаєте реальну відповідь за двадцять хвилин.
Останній пункт накопичувальний. Збережений набір для оцінки, це єдине, що робить оцінку кожного наступного релізу дешевою.
Шість запитів, які розрізняють новітні моделі
Загальні запитання дають схожі відповіді від будь-якої достатньо потужної моделі. Якщо хочете побачити різницю, тисніть на конкретну здатність.
- Тон під тиском.
Напиши клієнту записку про те, що ми пропустили дедлайн. Візьми відповідальність, не перепрошуючи надміру і без виправдань. Менше 120 слів.Відмінності в регістрі мовлення проявляються одразу. - Негативне обмеження.
Поясни [концепцію] без жодної аналогії чи метафори.Дотримання негативних інструкцій відрізняється набагато більше, ніж можна очікувати. - Сувора екстракція.
Витягни кожну дату, суму і сторону в масив JSON із точно цими ключами. Якщо поле відсутнє, використай null. Не роби припущень.Перевіряє дисципліну формату і схильність заповнювати прогалини. - Пригадування довгого контексту. Завантажте великий документ і запитайте про щось у середині. Показує реально придатний контекст, а не той, що заявлений.
- Визнання незнання. Запитайте про щось справді маловідоме або дуже нещодавнє. Найкраща відповідь, чітке «я не знаю» або пошук із джерелами. Вигадування тут дискваліфікує незалежно від будь-якого бенчмарку.
- Дотримання кількох обмежень одночасно. Дайте шість умов одразу і порахуйте, скільки з них виконано. Цей єдиний тест передбачає щоденну задоволеність краще за все інше в списку.
Відповідь зазвичай «обидві, для різних завдань»
Люди підходять до релізу, бажаючи почути вирок, а чесний результат після оцінки майже завжди розділений. Одна модель перемагає в письмі та тоні. Інша перемагає в суворій структурі та швидкості. У загальних міркуваннях вони настільки близькі, що це нічого не вирішує.
Це не викрутас, а реальний результат, і в нього є практичний наслідок. Якщо ви можете використовувати лише одну модель, ви обираєте, в якій категорії завдань бути гіршим. Якщо можете використовувати обидві, питання релізу перестає бути «чи варто перемикатися» і стає «які завдання переносити», а це набагато менше і не таке ризиковане рішення.
Це також змінює, що означає реліз для вас. Коли нові моделі з'являються в робочому просторі, де вже є кілька інших, ви повторюєте свої п'ять завдань, коригуєте маршрутизацію і продовжуєте роботу. Немає ні міграції, ні скасованої підписки, ні місяця користування гіршим варіантом через те, що ви визначилися до тестування.
Що робити в день релізу
Не змінюйте налаштування за замовчуванням одразу. У перший тиждень враження домінує новизна і приклади, які поширилися першими.
Повторіть свій набір для оцінки. Двадцять хвилин, якщо ви зберегли його з минулого разу.
Перевірте нудні речі. Вікно контексту, чи ваші наявні запити поводяться так само, і чи не змінилося щось, на що ви покладалися. Модель, яка загалом краща, може бути гіршою на вашому конкретному шаблоні, і це варто знати до того, як переносити на неї виробничу роботу.
Оновлюйте маршрутизацію по завданнях, а не повністю. Переносьте категорії, де нова модель явно перемогла, і залиште решту як є.
Зачекайте два тижні на обмеження. Слабкі місця нової моделі проявляються приблизно за два тижні широкого використання, і їх рідко згадують в анонсі.
Загальний фреймворк дивіться в як обрати модель ШІ, а механіку запуску двох моделей на одному запиті, у порівнянні моделей поруч.
- Складіть набір із п'яти реальних завдань зі своєї роботи і зберігайте його
- Запишіть, що має містити хороша відповідь, перш ніж читати будь-який результат
- Запускайте обидві моделі паралельно, щоб жодна не впливала на іншу
- Оцінюйте за обсягом редагування, а не за тим, як звучить результат
- Фіксуйте розмір розриву, адже взаємозамінні результати теж корисна інформація
- Окремо перевіряйте негативні обмеження та дотримання кількох умов одночасно
- Зачекайте два тижні, перш ніж переносити виробничу роботу на нову модель
- Оновлюйте маршрутизацію по завданнях, а не перемикайтеся повністю
Поширені запитання
Чи варто переходити на найновішу модель?
Не в день запуску і не повністю. Повторіть невеликий набір власних реальних завдань на обох моделях, оцініть, скільки редагування потребує кожен результат, і переносьте лише ті категорії, де нова модель явно перемагає. Новіша модель стабільно краща в одних речах і часом гірша в інших, особливо для наявних запитів, налаштованих під попередню версію.
Чому бенчмарки не збігаються з моїм досвідом?
Тому що вони вимірюють те, що можна оцінити автоматично, тобто завдання з правильною відповіддю. Більшість професійної роботи не має єдиної правильної відповіді, а якості, які визначають щоденну задоволеність (дотримання інструкцій, контроль тону, дисципліна форматування і вміння сказати «я не знаю»), здебільшого не вимірюються. Модель може очолювати кожен опублікований графік і все одно бути неприємнішою в роботі.
Як часто варто повторювати оцінку?
Щоразу, коли модель, яку ви використовуєте, отримує значний реліз, а зараз це означає кожні кілька місяців, плюс раз на квартал незалежно від цього. Постійний набір із п'яти реальних завдань перетворює це на двадцятихвилинну справу замість цілого дня, і це єдиний спосіб помітити, що маршрутизація, яку ви налаштували півроку тому, тепер неправильна.
Чи можна просто використовувати модель, яка перемагає загалом?
Можна, але тоді ви приймаєте гірші результати на передбачуваній частині своєї роботи. Стійкий висновок, коли люди оцінюють на власних завданнях, полягає в тому, що одна модель перемагає в письмі та тоні, а інша, у суворій структурі та швидкості, тоді як загальні міркування настільки близькі, що нічого не вирішують. Якщо обидві вам доступні, вибір стає індивідуальним для кожного завдання, а не для підписки.
Чи має значення, через який продукт ви звертаєтеся до моделі?
Модель залишається моделлю, тому якість результату загалом однакова, звідки б ви до неї не зверталися. Різниця в тому, чи можете ви порівнювати, чи зберігається контекст під час перемикання, і чи коштує вам новий реліз міграції, чи це просто ще один варіант у списку. Робочий простір із кількома моделями перетворює кожен реліз із рішення на коригування.