Два набора параметров, один и тот же GPU, решение, которое вы можете объяснить.

1. Сформулируйте вопрос, прежде чем готовить варианты

Полезное сравнение отвечает на конкретное решение: помогает ли увеличение максимальной длины избежать обрезанных ответов? Сохраняет ли уровень детализации нужные контуры? Завершается ли большая группа без ошибок? Выберите один вопрос и один параметр. «Найти лучшие параметры» — слишком широкая цель для первого сеанса.

Назовите A эталоном, а B — вариантом. Запишите точное изменённое значение. Одновременное изменение модели, размеров и числа проходов может дать другой результат, не показывая, какое именно изменение его объясняет. Оставьте такие пробы для отдельных сравнений.

2. Зафиксируйте небольшой корпус и правила оценки

Соберите одинаковые входные данные для A и B. Для первого ограниченного решения может хватить десятка случаев, если они охватывают сложности проекта: мелкий текст на изображении, длинный документ, отсутствующие данные или необычный формат. Это число — практический выбор, а не статистическая гарантия. Не включайте только те примеры, которые и раньше удавались.

Для каждого случая до теста запишите условия успеха. Отличайте предпочтение к оформлению от блокирующего дефекта. В помощнике по документам более приятный ответ может быть отклонён, если он выдумывает правило. Для изображения продукта привлекательный цвет не компенсирует исчезновение важного элемента.

Также задайте минимальное число принятых случаев, запрещённые дефекты и максимальное время проверки. Эти пороги, собственные для проекта, должны оставаться неизменными, пока вы изучаете результаты.

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, она приостанавливает вердикт: исходного корпуса не хватило, чтобы установить стабильность. Она сохраняет след обоих запусков, а не только наиболее благоприятного.

Избегайте выводов, которые не позволяет сделать ваш тест

Не выбирайте B только потому, что один из его результатов впечатляет, тогда как остальные ухудшаются. Не меняйте корпус по ходу дела, не считайте два повтора как две разные записи и не убирайте неудачу из знаменателя. Двенадцать представленных записей остаются двенадцатью случаями для объяснения, даже если некоторые из них не создали ни одного файла.

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

Сохраните краткое решение и следующую проверку

Ваше итоговое дело содержит корпус, две конфигурации, результаты, вердикты по идентификаторам и несколько строк вывода. Укажите выбранную настройку, причину и ограничение: «A сохранил преимущество на этих двенадцати вопросах; два ответа ещё нужно пересмотреть; дополнительные длинные документы не охвачены». Другой человек должен понять выбор, не присутствуя на сессии.

Сохраните A как контроль для следующей диагностики. Если ни один вариант не удовлетворяет критериям, не выбирайте ни один для поставки; сформулируйте новую гипотезу. Заложите время на копирование и проверку перед запуском этого продолжения. Завершённый тест с чётким ограничением уже даёт решение; он не обязывает продолжать до тех пор, пока не найдётся победитель.