Luna → Sol: как проверить ошибки маршрутизации и общую стоимость
Постройте правила передачи задачи от GPT-6 Luna к Sol и проверьте ошибочно принятые ответы. Учитывайте повторные вызовы и ручную работу, прежде чем заявлять об экономии.
Схема «сначала 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 единиц — это счёт провайдера?
- Нет. Это заранее составленный пример в условных единицах, а не тариф или результат теста моделей.


