Нормализация параметров генерации в мультипровайдерном стеке

Почему команда спорит о флагах

Спор редко начинается с качества ответа. Обычно все упирается в числа в конфиге. Один инженер ставит temperature 0.2 "для точности", другой выбирает 0.8 "для живого текста", и через пару минут разговор уходит во вкус. Так происходит потому, что число видно сразу, а полезность ответа надо проверять на реальных задачах.

Проблема глубже, чем кажется. У разных провайдеров одинаковые на вид флаги ведут себя по-разному. Temperature 0.7 у одной модели дает спокойный деловой тон, а у другой - длинный и рыхлый текст. То же касается top_p, штрафов за повторы и лимита токенов. Названия совпадают, но диапазоны, значения по умолчанию и внутренняя логика отличаются.

Даже единый OpenAI-совместимый слой не убирает эту путаницу сам по себе. Он упрощает интеграцию и сравнение моделей, но продуктовые команды и ML-инженеры все равно сверяют ответы между провайдерами. Если общей схемы нет, каждый новый тест снова сводится к ручной подгонке параметров.

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

Из-за этого разговор быстро портится. Команда обсуждает "правильный" temperature вместо доли полезных ответов, спорит о max_tokens без учета цены длинного вывода, меняет сразу несколько флагов и потом не понимает, что именно дало эффект. А еще часто берут удачный пресет для одной задачи и тянут его на все остальные.

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

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

Какие параметры свести к общему виду

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

• temperature задает степень случайности. Низкие значения делают ответы ровнее и предсказуемее. Более высокие помогают там, где нужен выбор формулировок, несколько идей или свободный стиль.
• top_p ограничивает хвост распределения вероятностей. Это еще один способ сдерживать случайность. Чем уже набор допустимых токенов, тем чаще ответ держится ближе к теме.
• max_tokens ограничивает длину ответа. Он влияет не только на формат, но и на цену, задержку и риск обрыва.
• presence_penalty и frequency_penalty уменьшают повторы. Первый подталкивает модель к новым словам и темам, второй сдерживает повтор уже использованных фрагментов.

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

С max_tokens все проще, но именно его чаще всего недооценивают. Для коротких задач вроде классификации или извлечения полей лимит должен быть жестким. Для диалога, объяснения или черновика письма его обычно поднимают. Это прямой рычаг расходов, и игнорировать его дорого.

Штрафы полезны не везде. Если задача требует точного повторения формата, сильные penalty легко ломают ответ. Зато в длинных диалогах и при генерации списков они часто убирают зацикливание и однообразные фразы.

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

Схема общих профилей

Когда команда договаривается не о каждом флаге отдельно, а о нескольких понятных режимах, спорить становится намного сложнее. Продукт говорит: "нам нужен строгий ответ", а не "давайте еще раз обсудим temperature 0.2 или 0.35".

На практике хватает четырех профилей.

• Строгий профиль. Temperature 0.1-0.3, top_p 0.9-1.0, короткий max_tokens, штрафы 0-0.3. Подходит для классификации, извлечения полей, коротких ответов саппорта и любых задач, где лишняя фантазия мешает.
• Обычный профиль. Temperature 0.4-0.7, top_p 0.9-1.0, средний лимит длины, штрафы 0-0.5. Это режим для большинства чатовых сценариев.
• Развернутый профиль. Почти те же настройки, что у обычного, но max_tokens выше в 1.5-2 раза. Нужен для инструкций, объяснений и черновиков документов.
• Творческий профиль. Temperature 0.8-1.0, top_p 0.85-0.95, штрафы 0.2-0.6. Полезен для идей, заголовков, писем и маркетинговых черновиков, но не должен быть режимом по умолчанию для бизнес-процессов.

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

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

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

Как собрать профили

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

Для каждого сценария достаточно записать две вещи: зачем нужен ответ и где у него предел по длине. Формулировок вроде "точно и коротко" или "можно свободнее, но не длиннее 400 токенов" уже хватает для работы. Пока цель не названа прямо, обсуждение temperature и top_p почти всегда остается вопросом вкуса.

Дальше нужен один и тот же набор запросов для всех моделей и провайдеров. Обычно хватает 10-15 запросов на сценарий, если среди них есть обычные случаи и несколько неприятных углов.

Рабочий порядок простой:

1. Возьмите 3-5 сценариев с самым большим трафиком.
2. Подготовьте для каждого короткий тестовый набор запросов.
3. Прогоните одинаковые запросы с 2-3 вариантами профиля или параметров.
4. Сравните не "понравилось или нет", а сбои по понятным метрикам.

Смотреть лучше на четыре вещи: повторы и словесный мусор, отклонение от формата, фактическую длину ответа и цену. Последний пункт часто недооценивают. Лишние 300 токенов в массовом сценарии очень быстро превращаются в заметный счет.

Не пытайтесь утвердить одно число для всех случаев. Лучше принять коридоры. Например, для строгих ответов держать temperature в диапазоне 0.1-0.3, а для черновиков 0.5-0.8. То же касается max_tokens: вместо одного общего потолка задайте отдельные рамки для короткого и длинного ответа.

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

Пример для саппорта, поиска и черновиков писем

Споры чаще всего возникают не из-за модели, а из-за разных ожиданий. Продукт просит "чуть живее", платформа хочет предсказуемый вывод, а команда саппорта не хочет ловить лишние фантазии в ответах клиентам.

Поэтому проще один раз завести общие профили и дальше оперировать ими. Тогда в коде живут не отдельные флаги, а понятные режимы.

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

Для поиска по базе и RAG-задач нужен другой режим. Низкий temperature и почти нулевые штрафы дают более сухой вывод. Модель чаще берет факт из найденных фрагментов и реже пытается "улучшить" формулировку. Это особенно полезно, когда ответ потом идет в ранжирование, проверку или аудит.

Черновики писем - обратный случай. Тут модели полезно дать больше воздуха: поднять temperature и разрешить более длинный ответ. Тогда она предлагает несколько нормальных формулировок, меняет тон и не застревает на одном абзаце.

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

Что делать с разницей между провайдерами

Проблема редко в самих флагах. Команда путается, когда один провайдер называет параметр max_completion_tokens, другой max_tokens, третий частично игнорирует штрафы, а четвертый меняет поведение temperature сильнее, чем ожидалось. Если оставить это как есть, любой разговор о качестве быстро превращается в спор о названиях.

Поэтому лучше ввести одну внутреннюю схему параметров и считать ее договором внутри команды. Обычно хватает 5-7 полей: temperature, top_p, лимит на длину ответа, два penalty, режим остановки и, если нужно, seed. Все, что приходит из SDK или от провайдера, сначала приводят к этой схеме, а потом переводят в формат конкретного API.

Профиль стоит хранить отдельно от модели, SDK и провайдера. Иначе профиль "саппорт-ответ" незаметно превращается в профиль "для одной модели через один клиент", а это ломает переносимость. Если вы меняете модель или подключаете ее через единый шлюз, приложение не должно заново решать, как назвать тот же параметр. Оно должно брать внутренний профиль и применять адаптер.

Удобно держать простую таблицу совместимости по каждому провайдеру и классу моделей:

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

Такая таблица экономит время на релизах. Если модель не понимает presence_penalty, не надо молча слать его дальше. Лучше явно задать безопасную замену: оставить 0, немного снизить temperature или сократить лимит ответа, если вы боретесь с лишней болтовней.

Числа нельзя переносить между моделями без проверки, даже если названия флагов совпадают. temperature = 0.7 на большой reasoning-модели и на компактной instruct-модели часто дает разный стиль, разную длину и разную склонность к повторам. То же касается лимита токенов: одна модель спокойно укладывается в 300 токенов, другая на том же лимите обрывает мысль или начинает спешить.

Рабочий вариант простой: фиксируете внутренний профиль, а затем делаете короткую калибровку по классам моделей. Обычно хватает трех классов: компактные модели, большие универсальные и reasoning-модели. После этого команда обсуждает уже не флаги провайдера, а поведение профиля: ответ стал длиннее, чаще повторяется, хуже держит формат. Это можно проверить тестами, а не мнениями.

Ошибки, которые ломают договоренности

Чаще всего спор начинается не из-за моделей, а из-за привычек команды. Один разработчик любит "повыше temperature", другой всегда поднимает max_tokens "на всякий случай", третий лечит повторы штрафами. Если общей схемы нет, профили быстро превращаются в набор личных предпочтений.

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

Еще несколько типичных промахов:

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

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

С temperature и top_p тоже легко запутаться. Эти ручки меняют похожую область поведения, но разными способами. Если двигать обе сразу без гипотезы, потом невозможно понять, что именно дало эффект. Проще зафиксировать один параметр и настраивать второй, а не менять все одновременно.

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

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

Проверка перед релизом

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

У каждого сценария должен быть профиль по умолчанию. Не "примерный", а конкретный: например, support_answer, search_summary, email_draft. Если профиль не задан, люди быстро начинают крутить флаги вручную, и через неделю уже непонятно, почему один и тот же запрос дает разный ответ.

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

Что проверить за несколько минут

• У каждого пользовательского сценария есть один профиль по умолчанию.
• Команда знает владельца профиля, порядок согласования и место, где хранится история изменений.
• Тесты гоняют все профили на одном и том же наборе запросов.
• Логи сохраняют фактические параметры каждого вызова: temperature, top_p, max_tokens, штрафы, модель и провайдера.
• Бюджет, длина ответа и время отклика укладываются в принятые лимиты.

Последний пункт часто пропускают. Профиль может выглядеть аккуратно в таблице, но на деле давать ответы на 30% длиннее нормы. Для саппорта это лишние токены и больший счет. Для внутреннего поиска - более медленные ответы. Для черновиков писем - просто шум.

Сравнение на одном наборе запросов быстро снимает лишние споры. Если email_draft с temperature 0.7 дает нормальный текст, а при 0.3 звучит слишком сухо, это видно сразу. Если support_answer при max_tokens = 900 уходит в длинные объяснения, это тоже видно без долгих обсуждений.

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

Что сделать дальше

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

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

После этого добавьте имя профиля в логи рядом с моделью и провайдером. Тогда при любом сбое видно не только model = x и provider = y, но и то, что запрос шел, например, с профилем для поиска или для длинного черновика. Это сильно ускоряет разбор качества, задержки и расходов.

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

Если вы используете RU LLM как единый OpenAI-совместимый шлюз, словарь профилей удобно держать рядом с этим слоем. Команды меняют один внутренний профиль, а не набор разрозненных параметров в каждом сервисе. Заодно проще держать маршрутизацию, биллинг и хранение данных внутри РФ в одном контуре, не переписывая клиентский код под каждого провайдера.

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

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