Безпечна заміна моделей LLM: людські мітки, показники за кожним кроком, налаштування зусиль

Зміна назви моделі в файлі конфігурації здається справою, яка займе п’ять хвилин. Однак у багатоетапних процесах роботи з ШІ це рідко так, і причина зазвичай не в самій новій моделі — а у критеріях, які ви використовуєте для її оцінки. Використовуючи реалістичний процес міграції фільтрувальної системи зі старої родини моделей, ви дізнаєтесь, як створювати надійні базові дані, присвоювати втрати окремим етапам, розрізняти застарілі запити від слабших моделей та розглядати зусилля моделі з дедукцією як параметр, притаманний кожному завданню, а не як загальну налаштування.

Конкретним поштовхом у цій ситуації є припинення підтримки. OpenAI оголосила 11 грудня 2026 року датою припинення роботи чотирьох моделей: gpt-5, її версій mini та nano, а також gpt-5-pro. Це план на момент написання тексту, тож перевірте його на офіційній сторінці з інформацією про припинення підтримки. Розглядуваний конвеєр залежав від двох найменших з цих моделей, тому їх заміна була обов’язковою. Існувало два варіанти заміни: gpt-5.4 у різних розмірах та gpt-5.6-luna. Назви моделей, стандартні налаштування та цінові програми швидко змінюються, тому розглядайте наведену нижче інформацію як моментальний знімок, а метод – як постійну складову.

Конвеєр, який підлягає міграції

Система обробляє приблизно 2 600 статей на місяць та звужує їх до близько 120 кандидатів, які потім людина переглядає вручну. Це звуження не є результатом одного лише запиту. Це агент, створений за допомогою LangGraph, який складається з близько десяти вузлів у графі, з яких десять — це різні виклики моделей. Три з цих викликів містять основну інформацію: брандмауер релевантності на вході, потім два класифікатори — один для типу контенту та один для теми. Після них йдуть перевірка новизни, крок оцінки та крок узагальнення.

Одна з властивостей конструкції впливає на кожне подальше рішення. Перший вузол створений для видалення шуму, а не для оцінки якості, і його два типи помилок мають дуже різну вартість:

• Хибне збереження є дешевим. Сильніша модель на наступних етапах або людський рецензент наприкінці це виявлять.

Хибний результат є постійним. Стаття позначається як переглянута та більше не потрапляє у процес обробки.

Будь-яка оцінка, яка симетрично ставиться до цих двох помилок, спричинить у вас хибні уявлення щодо роботи процесу обробки.

Конфігурація, яка надійшла

Кінцевий стан був навмисно несиметричним. Дев’ять із десяти запитів було перенесено на gpt-5.6-luna, який досі показує гарну продуктивність. Механізм перевірки релевантності залишився на gpt-5.4-nano; пояснення цього винятку зайняло більшу частину дослідження. Тепер кожен запит явно визначає рівень зусиль для міркувань замість того, щоб використовувати стандартні налаштування моделі, і цей вибір у кінцевому підсумку виявився важливішим за сам вибір моделі.

Вартість вже на ранньому етапі скоротила список кандидатів, ще до оцінки якості, але не через ціни в списку. Майже весь трафік оплачується за програмою обміну даними OpenAI, і Luna використовує ту саму більшу щоденну квоту, що й найдешевші моделі, які вже використовуються. Тому щомісячний рахунок залишається приблизно у кількох центах у будь-якому випадку. Більш потужні моделі того ж покоління належать до значно меншої квоти, яка була б вичерпана до полудня під таке навантаження, тож вони були виключені незалежно від якості.

Далі наведено чотири несподіванки у тому порядку, в якому вони з’явилися. Цей порядок також є корисним чек-лістом для вашої власної міграції.

Урок 1: не використовуйте стару модель як базу

Під час першої оцінки кожну кандидатську конфігурацію порівнювали з результатом застарілої моделі: наскільки нова конфігурація відтворює попередній результат? Це порівняння показало зниження якості на 31 статтю та призвело до пошуку дефекту в моделі, якого насправді не існувало.

Якщо дивитися назад, проблема є очевидною. Під час першого етапу обробки генеруються кандидатські варіанти, а 40–60 відсотків з них згодом видаляються людським рецензентом. Вимірювання збігу з цим результатом означає вимірювання збігу з фільтром, про середню якість якого вже було відомо. Кандидатський варіант отримує „нагороду“ за копіювання помилок старої моделі та піддається покаранню за їх виправлення.

Людські рішення вже є остаточною інформацією

У системі контролю версій існував набагато кращий набір міток. Етап людського перегляду видаляє записи зі списку кандидатів, і кожне видалення фіксується як коміт. Протягом місяця тестування перший етап перегляду скоротив кількість кандидатів з 122 до 72, а наступні етапи видалили ще більше. Порівняння цього коміту з його батьківським дає дві мітковані групи: статті, які людина залишила, та статті, які вона відхилила.

Переоцінка 31 „втраченого“ статті з урахуванням цих міток повністю змінила ситуацію. Сорок три відсотки з них були статтями, які рецензент і так збирався викинути. За мірками людського судження, фактичні втрати становили 15 хороших статей, що приблизно вдвічі менше, ніж здавалося спочатку. Ще краще те, що оскільки мітки можна поєднувати з рішеннями на кожному кроці, вони показують, який саме вузол призвів до втрати кожної з цих 15 статей. (Ці мітковані дані походять з налаштувань із gpt-5.4-mini, а не з версії Luna, яка постачалася, оскільки робота з Luna була припинена раніше.) Одному вузлу належала вина за цю зміну; жоден інший крок не змінився більш ніж на одну статтю. Локалізована проблема з 15 статтями в одному запиті набагато легше вирішувати, ніж незрозуміла втрата 31 статті.

Загальний урок: щоразу, коли хтось здійснює остаточний дзвінок у вашій системі, його дзвінок є основою для аналізу, і зазвичай вже існує запис про нього. Подивіться на черги схвалення, переваги модерації, повторно класифіковані заявки на підтримку чи зміни, які люди вносять у створені чернетки. Існуюча стаття про оцінку систем RAG за стадією збою наводить подібний приклад присвоєння помилок компоненту, який їх спричинив.

Вимірювання на кожному кроці також виявляє баги, які не пов’язані з міграцією. У цьому випадку було виявлено, що модуль перевірки новизни вигадує назви тем, які зовсім не зустрічаються у списку, який він отримує, створюючи різні вигадані назви для кожного зі своїх 24 відмовлень, причому це відбувається як зі старими, так і з новими моделями.

Урок 2: більш сувора модель може правильно розуміти ваш запит

Як тільки причину проблеми приписали фільтру тем, спокусливим рішенням було скоригувати його інструкції, поки нова модель не почне правильно працювати. Однак у цьому випадку це могло завдати серйозної шкоди, адже більш потужна модель на пізніших етапах обробки також завантажує саме ці файли з інструкціями. Пом’якшення правил, щоб модель першого етапу могла без проблем обробляти більше статей, послаблює той етап, який виконує справжню оцінку, і ніщо з того, що вимірюється на першому етапі, не дозволить це виявити.

Тож замість редагування інструкцій дослідження попросило модель саму пояснити свої дії. Для кожної статті, яку відхилив фільтр тем, була зафіксована заявлена причина від gpt-5.4-mini; загалом було здійснено близько двадцяти запитів.

Пояснення були послідовними. Вони назвали конкретні правила та вірно процитували початковий запит. У одному випадку модель майже дослівно повторила правило, яке виключало оптимізацію витрат ШІ „навіть при реалізації через API-шлюз“, та використала його для відхилення статті, яку рецензент насправді залишив.

Стара версія gpt-5-mini просто ніколи не застосовувала це правило. Після перевірки виявилося, що два з правил, які вона ігнорувала, справді були застарілими. Одне з них не передбачало винятків для схем обміну повідомленнями, створених всередині додатку; інше було написане до того, як API-шлюзи стали інфраструктурою, яку варто було регулювати. Ці два правила були виправлені, решта залишилися незмінними, а виправлення було внесено у окремий коміт, окремо від змін до моделі, щоб кожен елемент можна було оцінити незалежно.

Дешевий тест, який дозволяє розрізнити два протилежні діагнози

Це перевірка, яку варто провести спочатку під час будь-якої міграції. Коли новіша модель відхиляє більше елементів на етапі оцінки, причиною часто є краще дотримання інструкцій у поєднанні з запитом, який за рік втратив свою актуальність. Ознайомтеся з прикладами вказаних причин:

• Якщо пояснення правильно цитують ваші справжні правила, це означає, що запит вже застарів, і його корекція допоможе кожному етапу, який ним користується.
• Якщо модель посилається на правила, які явно не відповідають елементу, ваш запит є коректним, а проблема у самій моделі.

Ці висновки вказують у протилежних напрямках, і кількість відхилень сама по собі не дозволяє їх розрізнити.

Урок 3: суворіше рішення не обов’язково є гіршим

Механізм оцінки актуальності розповів схожу історію, але з іншої точки зору. У цьому етапі Luna відхилила вдвічі більше статей, ніж GPT-5.4-Nano. Очевидним було те, що Luna просто гірше справляється з цим завданням, і майже таке рішення й було ухвалено.

Однак цей механізм насправді відповідає на три окремі запитання: чи є матеріал достатньо свіжим, чи мова — англійська, та чи належить тема до сфери дії? Розглядалося лише комплексне рішення.

Розділення цього рішення на окремі частини виявило цікаві особливості. Щодо запитання про мову, моделі дали ідентичні результати, позначивши ті самі чотири статті. Уся різниця полягала у запитанні про тему: Luna відхилила 64 статті, а GPT-5.4-Nano — 32.

Читаючи пояснення Луни, можна побачити послідовні та переважно обґрунтовані висновки: серед відхилених ідей були бібліотека для пулів робочих процесів Go, платформа для створення голосових агентів та опис процесу міграції баз даних у хмару. Нічого не було пошкоджено. Луна інтерпретує поняття „основна увага“ вужче, ніж це мав на увазі автор запиту.

Це вимагає іншого рішення. Пошкоджений елемент потрібно виправити. Краще уникати занадто суворої, але обґрунтованої інтерпретації нечіткого запиту, яка застосовується на єдиному етапі, що передає дані далі, де помилки стають постійними. Саме тому цей запит залишився на моделі gpt-5.4-nano. Загалом, сумарний бал лише свідчить про те, що щось змінилося. Якщо один крок відповідає на кілька запитань, необхідно записувати кожну відповідь окремо, перш ніж формувати якісь теорії щодо моделі.

Урок 4: зусилля з міркування не передаються між моделями чи завданнями

Як тільки для фільтра було обрано gpt-5.4-nano, залишилось лише вирішити, скільки часу має приділити роздумам модель. Моделі міркування мають параметр зусилля, який приблизно контролює кількість внутрішніх обмірковувань перед наданням відповіді. Вихідною припущенням було те, що цей параметр діє як регулятор якості, який завжди налаштовується однаково, причому кожна модель реагує по-своєму.

Результати вимірювань показали два зовсім різні шаблони:

• При фільтрі релевантності підвищення параметра зусилля майже вдвічі збільшило кількість відхилень від gpt-5.4-nano, тоді як luna зовсім не реагувала на це налаштування.
• При фільтрі тематики та сама модель luna змінила кількість обраних статей на 49 у межах діапазону параметра зусилля, але все одно продовжувала відхиляти матеріали при найвищому значенні налаштування.
• Модель gpt-5-nano, яка більше не використовується, мала найбільш лояльну конфігурацію серед усіх.

Отже, твердження на кшталт „Luna потребує великих зусиль“ не є фактом, який можна повторно використовувати. Воно було актуальне для Luna під час виконання одного завдання, але не мало жодного значення під час виконання іншого. Зусилля — це властивість конкретної моделі під час виконання конкретного завдання, і кожна така пара потребує власного вимірювання.

Більша модель не може замінити це вимірювання. Окремий тест із 80 статей для перевірки релевантності, при якому кожна модель працювала з середніми зусиллями, призвів до 31 відхилення від GPT-5.4-mini, 34 — від Luna та 30 — від GPT-5.4-nano. Більша модель ледве змінила результати; повне вимкнення механізму міркувань у GPT-5.4-nano значно вплинуло на результати.

Зусилля також мають профіль витрат, який відрізняється від усього іншого, оскільки вони можуть зростати без чіткого верхнього ліміту. Підвищення рівня фільтрації на один рівень зусиль дозволило уникнути 10 відхилень при приблизно втричі більшому використанні токенів, але ця пропозиція була відхилена.

Що не вимірювалося

Чітке визначення недоліків є частиною цього методу.

• Конфігурація Luna, яка була надіслана, ніколи не оцінювалася за людськими мітками; цей етап було припинено раніше. Вона працює в умовах продакшну без жодної невдалої спроби використання моделі, що нічого не свідчить про зниження якості.
• Один даний пункт свідчить про те, що Luna працює гірше за gpt-5.4-mini у класифікації типу контенту: вона пропускає 9 хороших статей, тоді як gpt-5.4-mini — 5, причому рівень зусиль не було зафіксовано. Якщо обсяг результатів зменшується, саме цей етап потрібно перевірити першим.

Показники фільтрації за темами генеруються за допомогою механізму, який надсилає повний набір статей безпосередньо до відповідного вузла. У реальному процесі обробки на попередніх етапах вже була видалена більшість даних, тому абсолютні значення є завищеними. Механізм оцінки релевантності не схильний до цього, оскільки він також отримує повний потік даних під час роботи. Калібрування фільтра за темами ніколи не виконувалося, тому форма його кривої є надійною, але її абсолютні значення — ні.

Шум впливає з обох боків. Ранній висновок про те, що одна модель є „справді кращою“ через різницю у 10 пунктів, довелося скасувати, коли третя спроба з ідентичною конфігурацією дала протилежний результат. Рішення полягає у процедурному підході: необхідно кількісно оцінити відхилення між двома спробами з однаковою налаштуванням, перш ніж вважати наявність різниці між двома конфігураціями. Лише втрата 15 статей перевищує цей поріг, і вона обмежується одним вузлом.

Деталі вимірювань

Було використано два набори зразків. У експериментах із зусиллям усі 198 статей, які зберігалися у кеші, надсилалися безпосередньо до одного вузла, тож ніщо у верхній частині ланцюга не могло змінитися. У експериментах від початку до кінця через кожен вузол проходив зразок із 200 рядків; він містив 72 статті, схвалені людьми, та 49 статей, відхилених людьми.

Оцінка здійснювалася за цими людськими мітками:

• Конфігурація «Retired» (gpt-5-mini плюс gpt-5-nano): з 72 статей збереглося 48 хороших; 27 із 49 поганих пройшли далі.
• gpt-5.4-mini, який обробляв вузли оцінювання з застосуванням виправлень до запитів: з 72 збереглося 33; 18 із 49 пройшли далі.
• Конфігурація «Shipped» (luna у дев’яти з десяти викликів): ще не оцінювалася за жодним з наборів.

Останній запис залишається порожнім до щомісячного огляду, оскільки мітки існують лише після затвердження операції видалення, а у вересні на момент аналізу ще не відбулося жодного видалення.

Сигнал раннього виробництва

Дані про виробництво є частковою заміною. Luna почала працювати 30 серпня. Коефіцієнти включення за аналогічні періоди виглядають так:

• Попередні моделі з 1 по 29 серпня: 4,55 відсотка (121 модель із 2 658).
• Попередні моделі у останні вісім днів перед заміною: 4,86 відсотка (32 моделі із 658).
• Luna з 30 серпня по 6 вересня: 4,08 відсотка (26 моделей із 638).

Порівняння двох зіставлених вісмиденних періодів за допомогою тесту z з двома пропорціями дає значення 0,69, яке знаходиться у межах шуму. Для порівняння, попередня система показувала 3,98 відсотка протягом перших восьми днів серпня — що є більшою зміною у її власній історії, ніж зміна, внесена луною. Тиждень та один день — це короткий період, а коефіцієнт включення не вимірює якість, проте найбільш страшний сценарій — тихе «голодування» системи через луну — так і не виник.

Протягом періоду роботи системи Luna було створено перший розбір відхилень за кожним вузлом. У цей період Luna відхилила 603 статті. 42 відсотки з них були відхилені через фільтр релевантності, 38 відсотків — через фільтр типу контенту, 16 відсотків — через фільтр теми, а 3 відсотки — через перевірку новизни. На противагу цьому, попередня конфігурація відхилила 2 526 статей протягом періоду з 1 по 29 серпня, не зберігаючи жодної причини, тож для відтворення даних серпня доводилося переглядати статті заново, а не просто запитувати дані системи. Якщо ваша система сьогодні не фіксує причини відхилень на кожному етапі, її додавання — це найдешевше покращення, яке ви можете здійснити перед міграцією.

Обмеження абсолютної істини та однієї обробки

У людських оцінках є два вбудовані обмеження. Вони стосуються лише статей, які пройшли через стару систему обробки, тож нова конфігурація ніколи не зможе отримати визнання за порятунок чогось, що стара система помилково проігнорувала. Крім того, приблизно 79 рядків у зразку з 200 рядків зовсім не мають людського вердикту.

Дисперсія між послідовними запусками є великою. Три повторні запуски одного незмінного налаштування на ідентичних 200 рядах дали показники відхилення 37, 48 та 55 відсотків на одному вузлі, що значно більше, ніж можна пояснити шумом вибірки. Повторний повний запуск одного налаштування призвів до створення чотирьох нових елементів та втрати ще чотирьох. Перезапуск застарілого налаштування з використанням тих самих результатів, які воно саме створило у процесі виробництва, дозволив відновити лише 75 з 121 позначених товарів, тож воно узгоджувалося з власною історією лише приблизно у 62 відсотках випадків. На практиці один запуск може виявити різницю близько 20 пунктів на одному вузлі або близько восьми елементів у всьому конвеєрі.

Кращий підхід до перевірки окремих змін: перевіряти кожну зміну саме у тих елементах, які вона має виправити, разом із невеликим набором елементів, які їй слід залишити недоторканими, а на повномасштабну обробку покладатися лише як на грубий сигнал про можливі значні побічні наслідки. Один приклад швидкої корекції проілюстрував це. Він пересунув чотири цільові статті за межі вузла, який було виправлено, проте майже не змінив кінцевого результату, оскільки три з цих чотирьох пізніше були відхилені з непов’язаних причин.

Куди насправді йдуть токени

Міркування споживають токени для виведення результату, але саме результат не є тим, що вичерпує цей ліміт. Результат становив 13 відсотків усіх токенів у попередніх моделях та менше 3 відсотків у нових; оскільки запити є довгими, вхідні дані домінують.

На момент написання цього тексту програма обміну даними пропонує два щоденні пакети. Більший з них — 2,5 млн токенів на день — стосується моделі Luna та версій GPT-5.4 розміром nano та mini. Менший пакет — 250 тис. токенів на день — призначений для моделей середнього та великого розміру. У звичайний робочий день попередні моделі споживали приблизно 1,95 млн токенів, а нові версії — приблизно 1,15 млн токенів. Експортний період у один місяць, який складається переважно зі старої конфігурації та восьми днів роботи з новою, коштував би близько 4 доларів за тарифами Flex без будь-яких знижок.

За тисячу запитів ціни на моделі сильно відрізняються:

• gpt-5-nano: 0,32 долара
• gpt-5.4-nano: 0,52 долара
• gpt-5.6-luna: 0,65 долара
• gpt-5-mini: 1,49 долара
• gpt-5.4-mini: 3,29 долара (невеликий зразок)

Luna не є найдешевшою за ціною за запит, і це прийнятно. Вона коштує значно менше за запит порівняно з будь-якою з міні-моделей та використовує той самий ресурс, що й нано-моделі.

Додаткова плата за запис у кеш

У списку цін прихований один важливий момент, який варто уважно прочитати. Серед розглянутих моделей лише Luna стягує плату за запис у кеш — на 25 відсотків більше, ніж за звичайний вхідний даний без кешування. Оскільки запити надходять тут протягом усього дня без скупчень, записи в кеш закінчують свою дію між запитами: 57 відсотків вхідних даних до Luna було обліковано як записи в кеш, а лише 41 відсоток — як зчитування з кешу. Кешування все одно є вигідним, зменшуючи суму оплати на 23 відсотки порівняно з відсутністю кешування, але це ще далеко від 90 відсотків знижки, яку передбачає зчитування з кешу. Якщо ваш обсяг роботи мінливий, ви отримаєте більшу знижку; якщо ж запити надходять постійно, потрібно враховувати додаткову плату за запис у кеш.

Пастки API, які збивають кожен запит

Певна поведінка параметрів перетворює зміну імені на переривання роботи. Як повідомлялося на момент написання (перевірте з поточною документацією):

• Рівень зусиль за замовчуванням є непослідовним між різними версіями: середній для gpt-5, відсутній для сімейства 5.4 та знову середній для 5.6. Тож проста зміна імені моделі тихо змінює кількість зусиль, які докладається під час кожного запиту.
• Найвищий рівень зусиль доступний лише у моделях 5.6; його запит у моделі 5.4 призводить до невдачі кожного запиту.
• На кінцевій точці для доповнення тексту в чаті будь-які зусилля, вищі за «відсутні», у поєднанні з інструментами функцій відхиляються; такі запити мають надсилатися на кінцеву точку відповідей. Оскільки за замовчуванням у Luna рівень зусиль — середній, використання інструментів з Luna для доповнення тексту в чаті неможливе, якщо лише не було прямо знижено рівень зусиль.

Жоден з цих елементів не може бути відновлений під час виконання. Типова логіка повторних спроб обробляє помилки сервера, таймаути та обмеження швидкості, але не недійсні запити, тому погана комбінація моделі та параметрів призводить до невдачі для кожного рядка виконання, а не лише один раз. Перевіряйте комбінацію моделі та параметрів під час запуску процесу, ще до обробки першого рядка. Для детальнішої інформації про ці два кінцеві точки дивіться існуючу статтю „Items versus messages in OpenAI's Responses API“.

Основні висновки

• Ніколи не оцінюйте замінну модель за її відповідністю моделі, яку вона замінює; використовуйте задокументовані рішення людей як еталонні дані.
• Приписуйте кожну втрату певному етапу обробки та розділяйте кроки з кількома запитаннями на окремі, задокументовані вердикти.

Перш ніж знову надсилати запит, прочитайте вказані причини нової моделі. Точне наведення ваших правил означає, що запит застарів, а не модель.

Більш сувора, але обґрунтовна модель на етапі, де відмови є постійними, може бути краще обійдена, ніж виправлена.

Зусилля з міркувань належать до пари „модель–завдання“. Встановлюйте їх явно скрізь, вимірюйте на кожному кроці та пам’ятайте, що це єдиний вид витрат без верхньої межі.

Спочатку кількісно оцініть відхилення між запусками; довіряйте лише тим розбіжностям, які перевищують цей показник.

Найкориснішим документом для отримання перед схваленням міграції є не кількість відхилень, а кілька пояснень самої моделі щодо причин відмов.