Безопасная замена моделей LLM: человеческие метки, показатели за каждый шаг, настройки усилий

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

Конкретным триггером в этой ситуации является устаревание моделей. OpenAI объявила 11 декабря 2026 года датой прекращения поддержки четырех моделей: gpt-5, их мини- и нано-версий, а также gpt-5-pro. Это расписание действует на момент написания текста, поэтому уточните его на официальной странице с информацией об устаревании моделей. Рассматриваемый пайплайн использовал две самые маленькие из этих моделей, поэтому замена была обязательной. Существовало два варианта замены: gpt-5.4 в различных размерах и gpt-5.6-luna. Названия моделей, стандартные настройки и ценовые программы быстро меняются, поэтому рассматривайте приведенные ниже детали как моментальную снимку ситуации, а метод — как постоянный принцип работы.

Пайплайн, который подлежит миграции

Система принимает примерно 2 600 статей в месяц и сокращает их количество до около 120 кандидатов, которые затем ручно проверяются человеком. Это сокращение достигается не с помощью одного лишь запроса. Для этого используется агент, построенный с использованием LangGraph; в графе имеется около дюжины узлов, из которых десять представляют собой отдельные вызовы модели. Три из этих вызова содержат основную информацию: сначала происходит проверка релевантности, затем — два классификатора, один для определения типа контента и другой — для определения темы. После этого следуют проверка на новизну, шаг оценки и шаг подведения итогов.

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

• Ложное сохранение кандидата стоит недорого; более совершенная модель дальше в цепочке или человек-рецензент в конце смогут это обнаружить.

Ложное отклонение является постоянным. Статья помечается как просмотренная и больше не возвращается в обработку.

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

Конфигурация, поставляемая с продуктом

Конечное состояние было намеренно несбалансированным. Девять из десяти запросов были перенесены на gpt-5.6-luna, который пока проявляет хорошую работоспособность. Механизм оценки релевантности остался на gpt-5.4-nano; объяснение этого исключения заняло большую часть исследования. Теперь каждый запрос явно задаёт уровень усилий на обработку вместо того, чтобы использовать стандартные параметры модели, и это решение оказалось важнее самого выбора модели.

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

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

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

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

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

Решения людей уже являются эталонными данными

В системе контроля версий находился гораздо лучший набор меток. Этап человеческого рассмотрения удаляет записи из списка кандидатов, причем каждое удаление фиксируется как коммит. За месяц тестирования первый этап рассмотрения сократил количество кандидатов с 122 до 72, а последующие этапы удалили ещё больше записей. Сравнение этого коммита с его предшественником позволяет выделить две группы с метками: статьи, которые человек оставил, и статьи, которые он отклонил.

Пересчёт 31 статьи, считавшейся «потерянной», с учётом этих меток полностью изменил картину. Сорок три процента из них — это статьи, которые рецензент всё равно собирался отбросить. По оценкам человеческого суждения, фактически потеряно было 15 хороших статей, что примерно вдвое меньше, чем казалось изначально. Что ещё лучше, поскольку метки можно связать с решениями на каждом этапе, они показывают, какой узел привёл к потере каждой из этих 15 статей. (Эти меткированные данные получены при использовании gpt-5.4-mini, а не варианта Luna, поставляемого на рынок, так как эксперимент с Luna был прекращён раньше времени.) Один узел объясняет всю ситуацию; ни на одном другом этапе количество статей не изменилось более чем на одну. Локализованная проблема с 15 статьями в одном запросе гораздо проще разрешить, чем непонятную потерю 31 статьи.

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

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

Урок 2: более строгая модель может правильно интерпретировать ваш запрос

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

Поэтому вместо редактирования инструкций исследователи попросили модель сама обосновать свои действия. Для каждой статьи, отклоненной фильтром тем, была зафиксирована приведенная моделью gpt-5.4-mini причина; в общей сложности было сделано около двадцати запросов.

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

Старая версия gpt-5-mini просто никогда не соблюдала это правило. При проверке выяснилось, что два из игнорируемых ею правил действительно устарели: в одном отсутствовало исключение для схем обмена сообщениями, реализованных внутри приложения; в другом правило было сформулировано до того, как API-шлюзы стали инфраструктурой, заслуживающей упоминания. Эти два правила были исправлены, остальные оставлены без изменений, причем исправления были помещены в отдельный коммит, отдельно от изменений самой модели, чтобы их можно было оценивать независимо.

Дешевый тест для различения двух противоположных диагнозов

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

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

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

Урок 3: более строгий вердикт не обязательно означает худший результат

Механизм оценки актуальности рассказал похожую историю, но с другой точки зрения. На этом узле Luna отклонила вдвое больше статей, чем GPT-5.4-Nano. Очевидным выводом было то, что Luna просто хуже справляется с этой задачей, и это почти стало окончательным решением.

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

Разделение вердикта показало важные нюансы. По вопросу языка модели дали идентичные результаты, отметив те же четыре статьи. Вся разница заключалась в вопросе темы: Luna отклонила 64 статьи, а GPT-5.4-Nano — 32.

Анализ причин, приведённых Луной, показал логичные и в целом обоснованные выводы: среди отклонённых вариантов были библиотека для пулов рабочих процессов на Go, платформа для создания голосовых агентов и материал о миграции баз данных в облако. Ничего не было сломано. Луна интерпретирует понятие «основной фокус» более узко, чем это предполагал автор запроса.

Это требует иного решения. Неисправную проверку следует исправить. Лучше обойти ситуацию, когда неясный запрос интерпретируется обоснованно, но более строго, причём это происходит на единственном этапе, от которого зависит весь последующий процесс, где ошибки становятся необратимыми. Именно поэтому этот запрос остался на модели gpt-5.4-nano. В целом суммарная оценка показывает лишь то, что что-то изменилось. Если один шаг отвечает на несколько вопросов, необходимо записывать каждый ответ отдельно перед тем, как формулировать какие-либо выводы о модели.

Урок 4: усилия по рассуждению не переносятся между моделями или задачами

Как только для фильтра был выбран gpt-5.4-nano, оставался вопрос о том, насколько долго он должен размышлять. Модели для логических рассуждений имеют параметр усилий, который примерно контролирует объем внутренних размышлений перед ответом. Исходной гипотезой было то, что этот параметр действует как регулятор качества, всегда влияющий одинаково, причем каждая модель реагирует по-своему.

Результаты измерений показали два совершенно разных типа поведения:

• При использовании фильтра релевантности повышение уровня усилий практически вдвое увеличило количество отклонений от ответов gpt-5.4-nano, тогда как модель luna совсем не реагировала на это настройки.
• При использовании фильтра по тематике та же модель luna при изменении уровня усилий сместилась на 49 статей, но при максимальном уровне усилий продолжала отклонять статьи.
• Модель gpt-5-nano, уже не используемая, оказалась самой либеральной по настройкам среди всех.

Таким образом, утверждение вроде «Luna требует высоких усилий» не является фактом, который можно использовать повторно. Оно было верным для Luna при выполнении одной задачи, но не имело никакого смысла для неё при выполнении другой. Уровень усилий — это свойство конкретной модели при решении конкретной задачи, и каждая такая пара требует собственного измерения.

Более крупная модель не заменяет это измерение. Отдельное тестирование на 80 примерах с использованием механизма оценки релевантности, при котором каждая модель работала с усилиями среднего уровня, привело к 31 отклонению от GPT-5.4-mini, 34 — от Luna и 30 — от GPT-5.4-nano. Более крупная модель едва изменила результаты; полное отключение механизма рассуждения у GPT-5.4-nano привело к значительному изменению.

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

Что не измерялось

Четкое указание на недостатки является частью этого метода.

• Конфигурация Luna, отправленная на тестирование, никогда не оценивалась по сравнению с ручными метками; этот эксперимент был прекращен на ранней стадии. Она работала в производственных условиях без единого сбоя при вызове модели, что ничего не говорит о потере качества.
• Один единственный пример данных указывает на то, что Luna показывает худшие результаты по сравнению с gpt-5.4-mini в задаче классификации типов контента: она ошиблась с 9 хороших статей, тогда как gpt-5.4-mini — с 5, причем уровень усилий при этом не был зафиксирован. Если объем выводимого контента сокращается, это первый показатель, который следует проверить.

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

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

Подробности измерений

Были использованы два набора образцов. В экспериментах с усилием все 198 сохраненных статей направлялись непосредственно в один узел, поэтому ничто в верхнем уровне не могло измениться. В экспериментах «конец-конец» образец из 200 строк проходил через каждый узел; он включал 72 статьи, одобренные людьми, и 49 статей, отклонённых ими.

Оценка проводилась на основе этих человеческих меток:

• Устаревшая конфигурация (gpt-5-mini плюс gpt-5-nano): из 72 сохранено 48 хороших статей; 27 из 49 плохих статей прошли дальше.
• gpt-5.4-mini, обрабатывающий узлы оценки с применёнными исправлениями к запросам: из 72 сохранено 33; 18 из 49 прошли дальше.
• Действующая конфигурация (luna в девяти из десяти случаев): пока ещё не оценивалась по ни одному из наборов.

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

Сигнал раннего запуска производства

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

• Предыдущие модели с 1 по 29 августа: 4,55 процента (121 единица из 2 658).
• Предыдущие модели в последние восемь дней перед сменой: 4,86 процента (32 единицы из 658).
• Luna с 30 августа по 6 сентября: 4,08 процента (26 единиц из 638).

Сравнение двух совпадающих восьмидневных периодов с использованием теста z для двух пропорций дает значение 0,69, что полностью находится в пределах шума. Для сравнения, при предыдущей конфигурации за первые восемь дней августа было зафиксировано изменение на уровне 3,98 процента — что является более значительным колебанием в её собственной истории, чем изменение, внесённое Luna. Один неделя и один день — это короткий период, а показатель уровня включения не отражает качество, но самый опасный сценарий, при котором Luna бесшумно парализует работу системы, так и не произошёл.

В период работы системы Luna был впервые создан разбивка отклонений по отдельным узлам. За этот период Luna исключила 603 статьи. 42 процента из них были отклонены из-за правила релевантности, 38 процентов — из-за фильтра типа контента, 16 процентов — из-за фильтра по тематике, а 3 процента — из-за проверки новизны. В отличие от этого, при предыдущей настройке с 1 по 29 августа было исключено 2,526 статьи без сохранения ни одной причины, поэтому воссоздание данных за август требовало повторной обработки статей, а не простого поиска в производственных данных. Если ваша система сегодня не фиксирует причину отклонения на каждом этапе, её добавление — это самое дешевое улучшение, которое вы можете внести перед миграцией.

Ограничения исходных данных и одной запусковой процедуры

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

Дисперсия между последовательными запусками велика. Три повторных запуска с одинаковой настройкой на идентичных 200 строках привели к показателям отклонения в 37, 48 и 55 процентов на одном узле, что значительно превышает значение, объяснимое шумом выборки. Повторный полный запуск с одной и той же настройкой привёл к появлению четырёх новых элементов и потере ещё четырёх. Повторная обработка использованной ранее настройки с учётом того, что она сама произвела в процессе работы, позволила восстановить лишь 75 из 121 маркированного товара, таким образом, она совпадала со своей собственной историей примерно в 62 процентах случаев. На практике один запуск может выявить различия примерно в 20 пунктов на одном узле или около восьми элементов во всей цепочке обработки.

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

Куда на самом деле идут токены

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

На момент написания этого текста программа обмена данными предлагает два ежедневных лимита. Больший из них — 2,5 млн токенов в день — применим к модели Luna, а также к версиям GPT-5.4 размером Nano и Mini. Меньший лимит — 250 тыс. токенов в день — предназначен для моделей среднего и большого размера. В обычный рабочий день система потребляла примерно 1,95 млн токенов с использованием предыдущих моделей и примерно 1,15 млн токенов с новыми моделями. Экспортируемый месячный период, в основном с использованием старой конфигурации плюс восемь дней с новой, обошелся бы примерно в 4 доллара по гибким тарифам без каких-либо льгот.

Затраты на тысячу запросов сильно различаются у разных моделей:

• GPT-5-Nano: 0,32 доллара
• GPT-5.4-Nano: 0,52 доллара
• GPT-5.6-Luna: 0,65 доллара
• GPT-5-Mini: 1,49 доллара
• GPT-5.4-Mini: 3,29 доллара (малый объем данных)

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

Доплата за запись в кэш

В списке цен скрыта деталь, которую стоит внимательно прочитать. Среди рассматриваемых моделей только Luna взимает плату за запись в кэш — на 25 процентов выше, чем за обычный запрос без кэширования. Поскольку запросы поступают здесь постепенно в течение всего дня, а не сгруппированно, записи в кэш истекают между запросами: 57 процентов запросов к Luna были оценены как записи в кэш, а только 41 процент — как чтение из кэша. Кэширование всё равно экономит средства, снижая стоимость запросов на 23 процента по сравнению с отсутствием кэширования, но это далеко не 90 процентов скидки, которую предполагает скидка за чтение. Если ваш объем работы непостоянный, вы увидите большую скидку; если же запросы поступают постепенно, необходимо учитывать доплату за запись в кэш.

Ловушки API, приводящие к сбоям каждого запроса

Некоторые особенности параметров превращают процедуру переименования в причину сбоя. Как сообщалось на момент написания (проверьте актуальную документацию):

• Уровень усилий по обработке запроса неодинаков в разных версиях моделей: средний для gpt-5, отсутствует у моделей серии 5.4, а снова становится средним у моделей 5.6. Поэтому простое переименование модели бесшумно меняет степень обработки каждого запроса.
• Максимальный уровень усилий доступен только для моделей 5.6; запрос на его использование у модели 5.4 приводит к сбою каждого запроса.
• На конце точки ввода для дополнения текста в чат любой уровень усилий, превышающий отсутствие усилий, в сочетании с использованием функциональных инструментов отклоняется; такие запросы должны направляться на конец точки ответов. Поскольку стандартный уровень для Luna — средний, использование инструментов с Luna при дополнении текста в чат невозможно, если уровень усилий не снижен явно.

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

Основные выводы

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

Перед повторной настройкой запроса прочитайте указанные новой моделью причины. Точное соблюдение ваших правил означает, что запрос устарел, а не модель.

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

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

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

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