После того как китайская модель открытого исходного кода будет ограничена, первое, что нужно будет сделать, — это версию и уровень оценки.

Как только подобные ограничения снимаются, первое, что ломается, обычно не «можно ли это еще скачать?» но «может ли он по-прежнему основываться на том же наборе оценок?»

Сама модель еще есть, и зеркалирование можно синхронизировать, но проблема начинает смещаться от входа к сравнению. Версия, которая хорошо работает сегодня, будет иметь небольшие различия на другой машине из-за нарезки веса, версии токенизатора, параметров вывода или задержек зеркалирования. Просто глядя на каждый вывод, кажется, что он все еще работает; как только она возвращается в набор регрессии, кривая начинает расширяться. Раньше вам нужно было только посмотреть общий балл, чтобы решить, стоит ли обновляться, но теперь вам нужно сначала распаковать, «происходит ли это изменение из модели или из стека сервисов».

Настоящая проблема, вызванная ограничениями, заключается не в самом действии загрузки, а в разрушении отношений сравнения. Раньше вам нужно было сосредоточиться только на одной исходной версии, но теперь часто одновременно существуют официальные источники, зеркальные источники, внутренние кэши, квантованные версии и временные версии отката. Любую строку можно запустить, но результаты больше не будут иметь одну и ту же базовую линию. Как только оценочный набор будет разделен, команда быстро потеряет общий язык: отдел исследований и разработок говорит, что эта версия была улучшена, а продукт говорит, что онлайн-опыт не изменился. Специалисты по устранению неполадок должны сначала подтвердить, изменилась ли модель или изменилась среда вывода.

Самое неприятное в такой вилке то, что она не сразу проявляется в неисправности. В первый день разрыв между двумя средами составлял всего 0,3 балла. На второй день какой-то длинный текстовый образец начал дрейфовать. Откатившись на третий день, я обнаружил, что старые результаты воспроизвести невозможно. На этом этапе дискуссия уже не идет о том, «можем ли мы получить модель?» но «получим ли мы то же самое».

Что действительно следует закрыть в первую очередь, так это не вход для загрузки, а базовый уровень. По крайней мере, необходимо зафиксировать следующее:

• Хэш, версия токенизатора, метод квантования и параметры вывода файла модели.
• Набор оценок, слова подсказки, параметры выборки и логика постобработки.
• Инкапсуляция вывода, общая для онлайн-сервисов и автономной регрессии, чтобы предотвратить дрейф двух наборов реализаций.
• Сохранять старое изображение и базовую линию при откате, не полагаясь на реконструкцию памяти.

Эти вещи могут показаться тривиальными, но как только доступ к модели начинает ограничиваться, именно этот уровень тривиальности становится действительно ценным. Без них команда может делать ставку на следующее обновление только со словами «на этот раз все в порядке»; с их помощью они смогут, по крайней мере, подтвердить, заключается ли проблема в модели, стеке выводов или самом наборе данных.

Поэтому, когда это дело наконец дойдет до проекта, решение станет очень простым: можно ли получить модель — это только начало; от того, может ли один и тот же набор входных данных, тот же набор параметров и один и тот же набор образцов непрерывно работать на одной и той же линии, зависит, можно ли ее по-прежнему использовать стабильно. Пока сохраняется сравнительный калибр, в модели остается пространство для маневра; как только калибр разойдется первым, последующая замена, откат и устранение неисправностей станут дороже.