[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"guide-how-to-change-a-prompt-without-breaking-production::ru":3,"guide-related-how-to-change-a-prompt-without-breaking-production::ru":17},{"slug":4,"title":5,"excerpt":6,"body":7,"meta_title":5,"meta_description":8,"keywords":9,"category":15,"published_at":16,"updated_at":16},"how-to-change-a-prompt-without-breaking-production","Как менять промпт, не ломая прод","Промпты правят в текстовом поле и выкатывают за секунды — поэтому они ломают вещи тихо: ни компилятора, ни стектрейса, ни очевидного момента сбоя. Дайте им релизную дисциплину кода.","\u003Ch2>Правка промпта — это изменение в проде\u003C\u002Fh2>\n\u003Cp>Промпты не выглядят как код. Они живут в текстовом поле, читаются по-человечески, и правка занимает десять секунд. Именно поэтому они вызывают аварии, которые никто авариями не считает: нет компилятора, который отвергнет изменение, нет ошибки типов, нет стектрейса и нет очевидного момента, где что-то сломалось. Система продолжает отвечать. Просто отвечать иначе.\u003C\u002Fp>\n\u003Cp>Последствия реальны, даже когда правка была улучшением. Добавленная фраза «отвечай дружелюбнее» способна вытеснить инструкцию, которая держала вывод разбираемым. Ужесточение правила ради одной жалобы способно заставить систему отказывать в случае, который она раньше обрабатывала. Ни то ни другое не видно в доле ошибок, и оба доезжают до всех пользователей мгновенно.\u003C\u002Fp>\n\u003Ch2>Закрепите модель и версионируйте всю конфигурацию\u003C\u002Fh2>\n\u003Cp>Прежде чем относить изменение поведения к причине, нужно контролировать то, что меняется. Ссылайтесь на явную версию модели, а не на подвижный алиас, чтобы обновление на стороне провайдера не приехало в день, который вы не выбирали, и не было списано на вашу правку промпта.\u003C\u002Fp>\n\u003Cp>Дальше считайте промпт, версию модели, настройки поиска, описания инструментов и параметры сэмплирования одним версионируемым артефактом. Поведение — произведение всех этих множителей, а система, где промпт двигается независимо от версии модели, — это система, в которой двое могут искренне быть уверены, что ничего не менялось.\u003C\u002Fp>\n\u003Ch2>Соберите оценочный набор из настоящих сбоев\u003C\u002Fh2>\n\u003Cp>Вам нужен фиксированный набор входов для сравнения, и полезная его версия — не аккуратная выборка. Берите случаи из реального трафика, взвешивайте в сторону коммерчески важных сценариев и намеренно наполняйте неудобными: двусмысленные запросы, враждебные вводы, вопросы без хорошего ответа и каждый продовый сбой, который вы уже починили.\u003C\u002Fp>\n\u003Cp>Как можно больше проверяйте детерминированно: парсится ли вывод, соответствует ли схеме, есть ли обязательное поле, указывает ли ссылка на существующий документ. Остаётся суждение — его оценивают люди по написанной рубрике или модель в роли судьи, что масштабируемо, но требует сверки с человеческими метками, прежде чем её вердиктам можно доверять.\u003C\u002Fp>\n\u003Ch2>Прогоняйте набор на каждое изменение и ставьте шлюз\u003C\u002Fh2>\n\u003Cp>Вплетите оценку в тот же конвейер, где идут тесты, запускайте её на любое изменение версионируемой конфигурации и храните результаты рядом с породившим их коммитом. Смысл шлюза не в достижении целевого балла, а в том, чтобы требовать осознанного решения каждый раз, когда изменение роняет число. Большинство регрессов находится здесь, и найденные здесь не стоят ничего.\u003C\u002Fp>\n\u003Ch2>Выкатывайте на срез, а не на всех\u003C\u002Fh2>\n\u003Cp>Оценочный набор — прокси живого трафика и никогда не полный, поэтому дайте изменению встретиться с реальностью постепенно. Отдавайте новую конфигурацию малой доле запросов, сравнивайте быстро измеримые операционные сигналы — долю эскалаций, ошибки парсинга, повторы, задержку, правки пользователей — и расширяйте, только если они держатся.\u003C\u002Fp>\n\u003Cp>Держите предыдущую конфигурацию тёплой всё это время. Если откат означает выкладку, у вас не откат, а ремонт, и разница измеряется числом пользователей, увидевших плохую версию.\u003C\u002Fp>\n\u003Ch2>Держите аварийный выключатель с пригодным запасным путём\u003C\u002Fh2>\n\u003Cp>Поведенческие сбои — не те, что ловит мониторинг, поэтому нужен рычаг, гасящий функцию за секунды без выкладки. «Выключено» должно означать то, с чем продукт выживет: прежнюю конфигурацию, более простой детерминированный путь, очередь, направляющую работу человеку, или честное сообщение. Выключатель, превращающий функцию в страницу ошибки, в нужный момент никто не нажмёт.\u003C\u002Fp>\n\u003Ch2>Логируйте достаточно, чтобы объяснить регресс потом\u003C\u002Fh2>\n\u003Cp>Каждый сохранённый ответ должен нести версию конфигурации, которая его породила. Без этого логи фиксируют, что произошло, но не почему, — а это половина нужного для разбора и та половина, которую дольше всего восстанавливать. С этим жалоба на качество недельной давности превращается в запрос к данным, а не в спор, а вызвавший её случай становится следующей строкой оценочного набора.\u003C\u002Fp>","Правка промпта — это изменение в проде без компилятора и стектрейса. Разбираем релизную рутину, которая ловит регресс раньше, чем его заметят пользователи.",[10,11,12,13,14],"версионирование промптов","выкатка llm","офлайн-оценка","аварийный выключатель","версионирование моделей","deployment","2026-08-24T03:30:02+00:00",[18,23,27,31,36,40],{"slug":19,"title":20,"excerpt":21,"updated_at":22},"ai-tool-pricing-models-seat-vs-usage-vs-credits","Модели ценообразования AI-инструментов: за место, за использование и по кредитам","Три распространённых способа тарификации AI-инструментов — за место, за использование и по кредитам — и как понять, какой из них окажется дешевле именно для того, как работает ваша команда.","2026-08-05T14:32:26+00:00",{"slug":24,"title":25,"excerpt":26,"updated_at":22},"how-ai-image-generators-differ-diffusion-vs-the-rest","Чем различаются ИИ-генераторы изображений: диффузия и всё остальное, простыми словами","Нетехническое объяснение того, как работают ИИ-генераторы изображений, почему диффузионный подход стал доминирующим и каких практических различий стоит ждать от разных инструментов.",{"slug":28,"title":29,"excerpt":30,"updated_at":22},"how-to-automate-your-workflow-without-code","Как автоматизировать процесс без кода","Практическая последовательность для автоматизаций, которые выживают: выбрать подходящий процесс, описать его до того, как открывать инструмент, и предусмотреть сбои, ломающие большинство первых попыток.",{"slug":32,"title":33,"excerpt":34,"updated_at":35},"how-to-build-a-chatbot-without-coding","Как собрать чат-бота без программирования","Практический путь к работающему чат-боту на no-code инструментах: определить границы, подключить свой контент, обработать вопросы без ответа и понять реальную стоимость.","2026-08-05T14:32:27+00:00",{"slug":37,"title":38,"excerpt":39,"updated_at":22},"how-to-choose-an-ai-writing-assistant","Как выбрать ИИ-ассистента для письма","Практическая схема выбора инструмента ИИ для письма — как соотнести его с той работой, которую вы реально пишете, проверить возможности редактирования и не попасть на инструменты, выдающие уверенный, но обезличенный текст.",{"slug":41,"title":42,"excerpt":43,"updated_at":44},"how-to-evaluate-ai-output-quality-without-a-data-team","Как оценивать качество ответов ИИ без команды аналитиков","Чтобы понять, стала ли ИИ-функция лучше, исследовательская команда не нужна. Это руководство описывает маленький и дешёвый цикл оценки, который команда из двух человек способна завести и поддерживать при смене промптов и моделей.","2026-08-08T03:45:02+00:00"]