Luna → Sol: как проверить ошибки маршрутизации и общую стоимость

Постройте правила передачи задачи от GPT-6 Luna к Sol и проверьте ошибочно принятые ответы. Учитывайте повторные вызовы и ручную работу, прежде чем заявлять об экономии.

Чёрный рисунок каменного моста на светлой карточке, серо-зелёный фон, полосы и надпись Luna to Sol Routing.

Схема «сначала Luna, затем при необходимости Sol» имеет смысл только при допустимом уровне ошибок и меньшей полной стоимости. Цена первого вызова не учитывает дополнительную модель, повторы и человека. Сначала спроектируйте измерение, затем делайте вывод об экономии.

24 сентября 2026 года сверены документы Luna и Sol. Их роли здесь — инженерная гипотеза, не измеренный рейтинг качества. Учебный архив содержит подготовленные записи и не вызывает API.

Определите наблюдаемые условия

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

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

НаблюдениеВозможная веткаОснование
ID не подтверждён, нет цитатыДополнительная или ручная проверкаНет опоры на источник
Источник противоречивЧеловек или уточнениеВторое предположение скрывает неопределённость
Проверки пройдены, риск низокКандидат на принятие с выборочным контролемСмысловая ошибка ещё возможна
Отказ или остановка по политикеСоответствующая обработка отказаНе обходить ограничения другой моделью
Временный сбой связиОграниченный технический повторЭто не оценка качества

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

Проверяйте принятые записи

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

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

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

Считайте весь путь задачи

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

стоимость маршрута = первый этап + дополнительная модель
                  + повторы и инструменты + ручная работа

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

Выполните локальный контрпример

После распаковки:

python3 lab.py routing

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

ОбращениеМаршрутУсловные единицыПодготовленный исход
T1Принять1Верно
T2Передать дальше5Верно
T3Принять1Неверно
T4Человек10Верно

Итого 17 единиц. Условный вариант «всё через Sol» равен 16 только по токенам: его качество и ручная работа не измерены. Это неполное сравнение, по нему нельзя выбирать победителя. Пример показывает, почему четыре дешёвых первых вызова ещё ничего не доказывают. Один неверный ответ из двух принятых — не измеренная 50-процентная частота ошибок Luna.

Сделайте базовый вариант сопоставимым

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

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

Заранее задайте допустимый компромисс ошибок и расходов. На пилоте ручное подтверждение может остаться правильным решением. Добавляйте автоматизацию постепенно, когда её оправдывают результаты проверки. Цены Sol и цены Luna помогают читать usage, но не заменяют эксперимент на одинаковых задачах.

Часто задаваемые вопросы

Luna на первом этапе гарантирует экономию?
Нет. Нужно считать второй вызов, повторы и ручную обработку, а затем сравнивать с вариантом Sol для всех задач при сопоставимом качестве.
Достаточно уверенности, заявленной моделью?
Нет. Оценку нужно калибровать на независимой разметке и дополнять проверяемыми условиями и правилами риска.
17 единиц — это счёт провайдера?
Нет. Это заранее составленный пример в условных единицах, а не тариф или результат теста моделей.