Модельно-специфичные ветки

Когда общее правило перестаёт быть общим и требует отдельной архитектуры

Мечта выглядит прекрасно.

Команда пишет один универсальный промпт, кладёт его в систему, а модели меняет одной строкой:

MODEL=что-нибудь_новое_и_очень_умное

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

Иногда именно так и происходит.

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

Несмотря на то что ничего этого в материале нет.

В этот момент команда начинает подозревать, что замены имени модели в конфигурации оказалось недостаточно.

DES изначально не была универсальной

Название DES расшифровывается как DeepS Expert System.

Система задумывалась и создавалась именно для DeepSeek. Её ранние правила, режимы и способы управления поведением выросли из практической работы с конкретной моделью.

DeepSeek был не случайным провайдером, подключённым к готовой архитектуре.

Он был средой, под которую архитектура формировалась.

DES Visual училась использовать его особенности:

• склонность буквально выполнять жёсткие инструкции;
• способность работать с длинными наборами правил;
• реакцию на повторение запретов;
• поведение в режиме глубокого рассуждения;
• характерные способы достраивать визуальный контекст.

Проблемы DeepSeek не просто исправлялись снаружи. Они постепенно становились новыми правилами внутри DES.

Так система росла.

А затем появилась необходимость перенести работу на другую модель.

От DeepSeek к Sol

Полноценная DES Visual почти дошла до реализации. Калибровочная версия работала в полуавтоматическом режиме:

1. DES формировала JSON;
2. Кот отправлял его вместе с изображением в DeepSeek;
3. модель возвращала результат;
4. ответ вставлялся обратно в интерфейс DES.

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

Поэтому вместо завершения тяжёлой Visual появилась облегчённая ветка в форме обычного промпта для Sol.

Это было не создание совершенно новой системы с чистого листа.

Sol получила переработанные промпты DeepSeek.

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

Но постепенно выяснилось, что общий предок ещё не делает ветви взаимозаменяемыми.

Sol и DeepSeek по-разному реагировали на одни и те же инструкции. Правило, необходимое для удержания одной модели, могло чрезмерно направлять другую. Формулировка, которая помогала Sol не пропустить объект, заставляла DeepSeek этот объект придумать.

В какой-то момент промпт Sol попытались адаптировать обратно под DeepSeek.

И тут в лабораторию пришёл крестный ход.

Как промпт приказал модели галлюцинировать

Одна из задач DES Visual заключалась в определении РКК.

Ключевой вопрос ранней системы звучал примерно так:

Присутствует ли РКК в материале?

Система должна была сначала установить наличие объекта и только затем переходить к его описанию и классификации.

После переработки под Sol логика промпта изменилась. В инструкции накопились подробные правила о том, как распознавать РКК: какие признаки искать, как описывать одежду, людей и происходящее.

Когда этот промпт вернулся к DeepSeek, модель получила уже не нейтральную задачу:

Определи, есть ли здесь РКК.

Фактически она прочитала:

Здесь есть РКК. Найди его.

DeepSeek выполнил поручение.

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

Галлюцинация возникла не из пустоты. Все необходимые детали уже находились в промпте как признаки искомого объекта. Модель только собрала из них сцену, существование которой инструкция почти не позволяла поставить под сомнение.

Проблема была не в одном неправильном слове.

Изменилась сама постановка задачи.

Там, где раньше существовал выбор между «есть» и «нет», осталось требование найти.

Этот случай показал границу адаптации: промпт Sol нельзя было просто немного отредактировать и вернуть DeepSeek. Для него требовалось восстановить собственную архитектуру начиная с первого вопроса.

Одинаковая задача не означает одинаковый промпт

Разные модели могут получать одну бизнес-задачу:

Определить наличие объекта, описать подтверждённые признаки и вернуть результат в заданном формате.

Но способ надёжно получить этот результат может различаться.

Одной модели достаточно короткой инструкции.

Другой требуется явный порядок проверок.

Третья лучше выполняет задачу после разделения на несколько этапов.

Четвёртая способна принять видео целиком, тогда как остальным приходится передавать отдельные кадры.

Именно последнее произошло после появления Qwen в работе DES. Возможность отправлять видеофайл непосредственно модели изменила не только удобство интерфейса. Она изменила сам наблюдаемый материал.

Система, работающая по выбранным кадрам, анализирует набор статических состояний.

Система, получающая видео, может наблюдать последовательность, смену участников и развитие действия во времени.

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

Иногда модельно-специфичная ветка появляется из-за поведения модели.

Иногда — из-за возможностей её интерфейса.

А иногда модель просто видит другой объект исследования.

Не все различия требуют отдельной ветки

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

Через неделю в проекте появляются:

• версия для DeepSeek;
• версия для Sol;
• версия для Qwen;
• версия для быстрой Qwen;
• версия для Qwen по четвергам;
• экспериментальная версия, которую никто не решается удалить;
• файл FINAL_точно_FINAL_2.

Так модельно-специфичная архитектура превращается в модельно-специфичное болото.

Отдельная ветка оправдана, если различие устойчиво и влияет на результат.

Например:

• модель систематически нарушает общий порядок действий;
• нуждается в другой декомпозиции задачи;
• иначе трактует ключевое правило;
• поддерживает другой тип входных данных;
• использует иной механизм структурированного ответа или инструментов;
• требует собственного набора защитных инструкций;
• на общем промпте демонстрирует подтверждённую регрессию;
• исправление для неё ломает работу другой модели.

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

Ветвление должно лечить подтверждённую несовместимость, а не тревогу архитектора перед запуском нового API.

Что должно оставаться общим

Модельно-специфичные промпты не означают, что каждая ветка получает собственную реальность.

Общими остаются:

• цель системы;
• предметные определения;
• бизнес-правила;
• входной и выходной контракты;
• требования к безопасности;
• правила работы с неизвестным;
• критерии качества;
• основной корпус контрольных кейсов.

Это нормативное ядро.

Оно отвечает на вопрос:

Что система должна сделать?

Модельная ветка отвечает на другой:

Как добиться этого поведения от конкретной модели?

Разделение этих уровней защищает систему от двух крайностей.

Без общего ядра ветви начинают незаметно решать разные задачи.

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

Для модели A делай X. Для модели B не делай X, кроме случая Y. Для модели C считай, что предыдущий абзац написан не тебе.

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

Архитектура ветвей

Управляемая система может состоять из нескольких слоёв.

1. Каноническая спецификация

Здесь хранятся определения, ограничения и ожидаемое поведение, не зависящие от модели.

Например:

• сначала определить наличие объекта;
• не описывать отсутствующий объект;
• отделять наблюдение от вывода;
• сохранять хронологию;
• возвращать результат по установленной схеме.

2. Модельная реализация

Каждая ветка переводит общие требования на язык конкретной модели.

Она может определять:

• структуру инструкции;
• количество этапов;
• размещение примеров;
• способ запроса самопроверки;
• формат передачи контекста;
• работу с изображениями или видео;
• использование встроенного структурированного вывода;
• допустимый объём правил.

3. Адаптер вызова

Отдельный слой отвечает за технические особенности API:

• роли сообщений;
• параметры генерации;
• передачу файлов;
• инструменты;
• схемы ответа;
• обработку ошибок;
• повторные попытки.

Не следует зашивать эти различия непосредственно в предметные правила.

Технический способ отправить изображение не должен незаметно менять определение того, что считается наблюдаемым объектом.

4. Нормализация и проверка

Ответы разных моделей приводятся к общему контракту и проходят единые предметные проверки.

Иначе сравнение превратится в конкурс литературных стилей.

Общие и веточные контрольные кейсы

Основная часть gold-корпуса должна проверять общую задачу независимо от модели.

Если правило требует не выдумывать отсутствующий объект, оно действует и для DeepSeek, и для Sol, и для Qwen.

Но этого недостаточно.

У каждой ветки могут существовать собственные регрессионные случаи:

• характерная галлюцинация конкретной модели;
• сбой её режима рассуждения;
• ошибка передачи изображения;
• нарушение формата при определённом API;
• особая чувствительность к контексту.

Поэтому контрольный набор полезно разделить на два слоя:

1. общие предметные кейсы — подтверждают, что все ветви решают одну задачу;
2. веточные регрессии — не позволяют конкретной модели повторить уже известную ошибку.

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

Но DeepSeek забывать его уже нельзя.

Правило нельзя переносить без истории

Допустим, в ветке Sol появилось новое ограничение.

Можно автоматически скопировать его во все остальные промпты.

Но сначала необходимо узнать, почему оно возникло.

Это может быть:

• общее предметное правило;
• исправление ошибки Sol;
• компенсация особенностей конкретного API;
• временная заплатка;
• правило, связанное только с одним видом входных данных.

Только первый тип обязан перейти во все ветки без изменения смысла.

Остальные требуют отдельной проверки.

Полезный журнал переноса должен отвечать:

• откуда пришло правило;
• какую проблему оно решало;
• является ли проблема общей;
• в какие ветки правило перенесено;
• как адаптирована формулировка;
• на каких кейсах проведена проверка;
• что сознательно не переносилось и почему.

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

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

Но тогда Историк остался бы без любимой работы.

Как не утонуть в ветках

Если поддерживаются пять задач и четыре модели, теоретически можно получить двадцать промптов.

А затем ещё тестовые, краткие, reasoning- и video-варианты.

Чтобы система оставалась управляемой, нужны ограничения.

Ветвиться по доказательству

Новая ветка появляется после подтверждённого расхождения, а не сразу после знакомства с новой моделью.

Хранить общее правило один раз

Каноническая спецификация не должна вручную копироваться во все файлы. Ветки реализуют её требования, но не становятся независимыми конституциями.

Вести журнал переноса

Каждое общее изменение получает отметку о состоянии всех ветвей:

• применено;
• адаптировано;
• не требуется;
• отложено;
• отклонено с объяснением.

Проверять ветви одним экзаменом

Общие кейсы показывают, продолжают ли реализации решать одну задачу.

Сохранять контрольные версии

Новая адаптация не заменяет старую до сравнения. Иначе неудачный перенос уничтожит последнюю рабочую точку.

Закрывать тупиковые ветки

Экспериментальная версия может быть полезна как исторический материал, но не обязана вечно числиться активной.

Архив — это место памяти.

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

Универсальный промпт всё ещё полезен

Из всего сказанного не следует, что универсальные промпты бесполезны.

Они подходят:

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

Универсальный промпт — хороший общий предок.

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

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

Разные модели — одна система

Зрелая архитектура не обязана стирать различия между моделями.

Она должна удерживать общее там, где это действительно общее:

• определения;
• правила;
• контракт;
• доказательства;
• критерии качества.

И разрешать различия там, где они подтверждены практикой:

• структура промпта;
• порядок действий;
• способ передачи материала;
• модельные защиты;
• технический адаптер;
• регрессионные кейсы.

Модельно-специфичная ветка — не признание поражения универсального промпта.

Это признание реальности.

Одна должностная инструкция может описывать работу всего отдела.

Но если DeepSeek снова увидел крестный ход, Sol начал спорить с Конституцией, а Qwen принёс в лабораторию видео вместо кадров — рассадить сотрудников по отдельным кабинетам будет разумнее, чем ещё раз увеличить шрифт общего приказа.