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

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

Проблему такого рода обычно трудно рассматривать как архитектурную проблему. На этапе разработки я видел только «может работать». Зайдя в интернет, я обнаружил, что выбор модели уже записан в бизнес-логику. Некоторые поля адаптируются только к одному формату возврата, некоторые повторные попытки распознают только один метод отклонения, а некоторые резервные исключения по умолчанию используют исходную модель, чтобы дать более подробное объяснение. Как только были введены ограничения, все эти скрытые груды оказались обнажены.

Поведение по умолчанию привяжет модель к бизнесу

На этапе доступа модель часто рассматривается как добавление SDK, подключение API и добавление слова-подсказки. После подключения сложнее всего подчистить не сам вызов, а ветки, разросшиеся вокруг дефолтного поведения. Должен ли вывод быть строго в формате JSON, следует ли повторить вызов инструмента после сбоя, где обрезать слишком длинные входные данные и на каком уровне размещать подсказки по контролю рисков. Эти вопросы часто попадают в бизнес-код.

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

Роль нейтрального слоя — распространить неявные предположения

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

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

Не все сцены достойны этого слоя

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

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

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