Смена модели: почему отлаженный промпт перестаёт работать

С чего это начинается

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

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

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

Вы прогоняете ещё раз. Приходит другая структура. Ещё раз — снова другая.

Обычный вывод: модель слабее, работать нельзя. Вывод сделан без замера. Сломалась не обязательно модель — сломался промпт, который вы за три месяца незаметно подогнали под привычки одной конкретной.

Промпт — это не текст, это интерфейс

Когда промпт долго живёт, он обрастает умолчаниями. Вы однажды написали «сведи в таблицу» — модель сама выбрала колонки, они вам подошли, вы их не стали закреплять. Написали «коротко» — модель сама решила, что коротко значит без вступления. Не написали, что делать, если поля в письме нет, — модель сама ставила прочерк.

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

Отсюда правило: при переносе на другую модель промпт нужно не «улучшать», а доукомплектовывать — выписывать явно всё, что раньше подразумевалось.

Три оси, по которым расходятся модели

Ось первая: длина контекста и поведение у её границы

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

Практически важнее другое: поведение у границы важнее самой границы. Задолго до формального предела качество разбора начинает падать неравномерно — начало и конец документа обрабатываются надёжнее середины. Это измеренный эффект, а не впечатление: в работе «Lost in the Middle» показано, что качество ответа выше, когда нужный фрагмент стоит в начале или в конце контекста, и падает, когда его приходится доставать из середины. Ответ при этом остаётся уверенным по форме: вы получите не предупреждение «я разобрал не всё», а таблицу, в которой не хватает трёх строк.

Так и вышло в примере выше: два последних письма не были «признаны неважными», разбор до них просто не дошёл.

Ось вторая: следование формату

Инструкцию формата модель может понимать как контракт или как пожелание. Разница видна не на одном прогоне, а на пяти: если пять раз подряд приходит одна и та же структура — это контракт, если структура плавает — пожелание.

Пожелание не лечится словом «обязательно». Оно лечится тем, что формат перестаёт быть описанием и становится образцом: вы показываете одну заполненную строку и просите повторить её ровно. Описание формата модель пересказывает своими словами, образец — копирует.

Ось третья: работа с длинным документом

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

Отсюда правило: длинный документ не разбирается одним запросом. Дробление на разделы с отдельным запросом по каждому дороже по числу действий и дешевле по числу проверок.

Три замера до переписывания

Замер даёт формулировку не «вроде хуже», а «формат держит в двух случаях из пяти». Второе можно обсуждать с руководителем, первое — нет.

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

Замер 2. Где начинает мазать на длине. Возьмите свой типичный документ и вставьте в него контрольную фразу — синтетическую, которой там быть не может: «ответственный по этому пункту — Иванов И.И., внутренний номер 77». Вставьте её в начало и спросите модель, кто ответственный. Потом уберите и вставьте ту же фразу ровно в середину. Потом в конец. Потом возьмите документ вдвое длиннее и повторите три раза.

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

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

Как переписать промпт

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

Что выписать явно, если раньше это подразумевалось:

• Колонки и их порядок. Не «сведи в таблицу», а перечисление полей в нужной последовательности.
• Что делать, когда поля нет. Без этого правила пробел заполняется правдоподобным значением. Нужен один конкретный маркер, например слово ПУСТО, — и запрет на любые другие способы обозначить пропуск.
• Запрет на вступление и послесловие. Иначе таблицу приходится вычищать руками.
• Одна задача на запрос. Цепочка «разбери, посчитай, сформулируй вывод» в одном промпте разваливается по всем трём осям сразу.

Готовый каркас, в который подставляются ваши поля:

Последний пункт — дешёвая проверка полноты: счётчик объектов вы сравниваете с тем, сколько их должно было быть, и видите недобор, не вычитывая таблицу целиком. Счётчик ПУСТО показывает, насколько модель удержалась от домысливания.

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

Где приём не работает

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

Жёсткая рамка сушит содержательные задачи. Извлечение полей, классификация, свод — да. Черновик письма, разбор ситуации, формулировка — нет: под строгим шаблоном ответ становится механическим.

Пять прогонов — грубый инструмент. Он ловит разницу между «почти всегда» и «примерно через раз», но не редкие сбои: если сбой случается в одном прогоне из десяти, пять прогонов пропустят его с вероятностью 0,9⁵ ≈ 0,59 — то есть чаще, чем в половине случаев. При высокой цене ошибки пяти прогонов недостаточно.

Замер стареет. Модель обновилась — результат недействителен. Записывайте рядом с дробью название модели и дату: поставщики публикуют обновления линеек отдельным списком, и состав доступных версий меняется.

Сканы и распознавание. Если документ пришёл фотографией, вы проверяете качество распознавания, а не качество модели. Замер 2 на скане покажет ерунду.

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

Доступность модели не равна разрешению отправлять в неё данные. Это отдельный вопрос, он решается не промптом и не замером, а до них.

Что сделать сегодня

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

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