1. Сформулюйте питання, перш ніж готувати варіанти
Корисне порівняння відповідає на конкретне рішення: чи запобігає збільшення максимальної довжини обрізаним відповідям? Чи зберігає рівень деталізації потрібні контури? Чи завершується більший пакет без помилок? Виберіть одне питання й один параметр. «Знайти найкращі налаштування» — надто широко для першої сесії.
Назвіть A еталоном, а B — варіантом. Занотуйте точне змінене значення. Зміна одночасно моделі, розмірів і кількості проходів може дати інший результат, не виявляючи, яка саме зміна його зумовила. Залиште ці спроби для окремих порівнянь.
2. Зафіксуйте невеликий корпус і правила оцінювання
Зберіть однакові вхідні дані для A і B. Дюжини випадків може бути достатньо для першого обмеженого рішення, якщо вона охоплює складнощі проєкту: дрібний текст на зображенні, довгий документ, відсутні дані або незвичний формат. Ця кількість — практичний вибір, а не статистична гарантія. Уникайте включення лише тих прикладів, які вже вдавалися.
Для кожного вхідного запиту напишіть умови успіху до тесту. Відрізняйте вподобання щодо оформлення від блокуючого дефекту. У документальному асистенті приємніша відповідь може залишитися неприйнятою, якщо вона вигадує правило. Для візуального продукту привабливий колір не компенсує зникнення важливого елемента.
Також установіть мінімальну кількість прийнятих випадків, заборонені дефекти та максимальний час перевірки. Ці порогові значення, властиві проєкту, мають залишатися незмінними, коли ви розглядаєте результати.
| Що зафіксувати | Приклад нотатки | Чому це важливо |
|---|---|---|
| Вхідні дані | cas-01 до cas-12, ті самі файли й ті самі формулювання | Порівнювати ті самі складнощі |
| Критерій якості | Відповідь, перевірна за документом і без вигадок | Уникнути того, щоб плавний результат приховував помилку |
| Критичний збій | Відсутнє правило, подане як достовірне | Відхилити дефект, навіть якщо загалом виглядає краще |
| Змінна | A: 128; B: 256 нових токенів щонайбільше | Приписати різницю ідентифікованій зміні |
3. Зберігайте ту саму сесію та ті самі залежності
Збережіть модель, її версію, розширення, обчислювальний рушій та інші параметри. Використовуйте те саме середовище й той самий GPU, не запускаючи іншої обробки між двома варіантами. Занотуйте те, що ви не можете контролювати: видиму сторонню активність, примусову зміну версії чи інше завантаження. Порівняння, на яке вплинули ці зміни, вимагає більшої обережності.
Якщо інструмент використовує випадкове зерно й дозволяє його зафіксувати, збережіть це значення для кожної пари проходів. Це полегшує порівняння, але не гарантує однакового результату всюди. PyTorch зазначає, що повна відтворюваність не гарантується між версіями чи платформами навіть за однакового зерна.
Створіть дві теки, A і B, з однаковим списком ідентифікаторів. Зберігайте необроблені результати до будь-якого ручного виправлення. Подальше доопрацювання має відображатися як окрема операція з власним часом роботи, а не приписуватися налаштуванню, яке створило початковий файл.
4. Зробіть контрольний прохід, а потім порівняйте пари
Спершу перевірте, що простий вхід проходить аж до отриманого файлу чи відповіді. Цей прохід перевіряє метод. Окремо зазначте перше завантаження чи особливу підготовку: не порівнюйте повний запуск A з проходом B, де всі елементи вже завантажені.
Виконайте ті самі випадки для A і B. Якщо інструмент дозволяє, чергуйте порядок, а потім повторіть кілька вирішальних пар у зворотному порядку. Перевірте, чи не керує всім висновком якийсь окремий результат або перевага порядку.
Фіксуйте також помилки та відхилені результати. Якщо B зазнає невдачі на великому вході, не вилучайте його з таблиці, щоб покращити середнє. За потреби усуньте причину в окремому тесті B2. Так ви зберігаєте зрозуміле порівняння замість теки, де варіант змінюється в міру труднощів.
5. Відокремте прийнятий результат і спостережуваний час
Спершу оцініть якість у тому розмірі чи інструменті, де будете використовувати. Якщо можливо, тимчасово приховайте назви A і B на час оцінювання. Одна людина може просто переглянути результати у перемішаному порядку, а потім відновити їхню відповідність. Дотримуйтеся заздалегідь оголошених критеріїв і короткої причини для кожної відмови.
Щодо часу виберіть єдине визначення: наприклад, від запуску до збереження повного результату. Потім відокремте людський контроль і виправлення. Секундомір навколо виклику GPU не завжди вимірює завершене обчислення: у PyTorch/CUDA операції можуть бути асинхронними. Якщо хочете ізолювати обчислення, використовуйте метод вимірювання, задокументований в інструменті.
Якщо повтори перекриваються або хронометраж залишається приблизним, зазначте «різниця в тривалості непереконлива». Невелика розбіжність в одному запуску не виправдовує відсоток виграшу, поданий як певний.
Приклад: 128 чи 256 нових токенів для помічника з документів
Невелика команда хоче повних відповідей на дванадцять фіксованих запитань. Вона зберігає ту саму модель, ті самі документи, ту саму інструкцію й той самий GPU. Змінюється лише ліміт відповіді: A дозволяє 128 нових токенів, B — 256. У Transformers max_new_tokens обмежує генерацію, не рахуючи токени вхідного тексту. Токен — це не слово: ліміт не визначає точної кількості речень.
Перед тестом команда встановлює ілюстративне правило: щонайменше десять прийнятних відповідей із дванадцяти й жодної вигаданої норми. Наведена нижче таблиця — це вигаданий сценарій опрацювання результатів. Вона не описує виміряного помічника й не передбачає впливу цих значень на вашу модель.
A досягає мінімуму, B отримує більше прийнятних відповідей, але зберігає критичний дефект. Рішення — залишити A для цього обсягу з перевіркою відповідей і з'ясувати причину дефекту B перед наступним порівнянням. Більша довжина не є ні доказом якості, ні певною причиною вигадки.
Команда повторює запитання, що розрізняють A і B, та два вже успішні запитання. Якщо дефект з'являється і з A, вона призупиняє вердикт: початкового корпусу не вистачило, щоб встановити стабільність. Вона зберігає слід обох проходів, а не лише найсприятливіший.
| Критерій сценарію | A: максимум 128 токенів | B: максимум 256 токенів |
|---|---|---|
| Прийнятні відповіді | 10 з 12 | 11 з 12 |
| Критичні дефекти | 0 | 1 вигадане правило |
| Тривалість | Варто зафіксувати під час реальної сесії | Варто зафіксувати тим самим методом |
| Дотримання заявленого правила | Так, у цьому обмеженому сценарії | Ні, попри найкращий загальний результат |
Уникайте висновків, яких не дозволяє ваш тест
Не обирайте B лише тому, що один із його результатів вражає, тоді як інші погіршуються. Не змінюйте корпус на ходу, не рахуйте два повтори як два різні записи та не вилучайте невдачу із знаменника. Дванадцять поданих записів залишаються дванадцятьма випадками, які потрібно пояснити, навіть якщо деякі з них не створили жодного файлу.
Обране налаштування чинне для розглянутих записів, версій і критеріїв. Воно може вже не підходити для документа, що в десять разів довший, або для інших зображень. Поступово додавайте репрезентативні випадки. Це розширює контроль, але не перетворює невеликий тест на сертифікацію системи.
Збережіть коротке рішення та наступну перевірку
Ваша підсумкова папка містить корпус, обидві конфігурації, результати, вердикти за ідентифікаторами та кілька рядків висновку. Укажіть обране налаштування, причину та обмеження: «A збережено на цих дванадцяти запитаннях; дві відповіді ще потребують доопрацювання; додаткові довгі документи не покриті». Інша людина має зрозуміти вибір, не бувши присутньою на сесії.
Збережіть A як контрольний зразок для наступної діагностики. Якщо жоден варіант не відповідає критеріям, не беріть жодного для доставки; сформулюйте нову гіпотезу. Закладіть час на копіювання та перевірку, перш ніж запускати це продовження. Завершений тест із чітким обмеженням уже дає рішення; він не зобов’язує продовжувати, доки не знайдеться переможець.