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

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

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

По умолчанию предполагается, что он будет привязан и возвращен первым.

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

Распространение и откат увеличивают небольшие изменения.

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

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

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

Не во всех проектах стоит сначала прорабатывать этот уровень.

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

Так называемая печать часто просто возмещает команде сразу сэкономленные затраты на проверку, распространение и откат. Модели меняются, а ссылки невозможно стабилизировать по счастливой случайности. Нам нужно сначала разобрать ссылку проверки, прежде чем мы сможем говорить о том, можно ли продолжать использовать модель.