Единица 5 / 11

Выбор модели: правильная модель для правильной работы

Прибыль:

  • Можно сравнить семейство моделей (быстрых/сбалансированных/мощных) по возможностям, скорости и стоимости.
  • Разрабатывает стратегии выбора модели и маршрутизации в зависимости от сложности задачи.
  • Выбор модели основывается на фактических данных с небольшим набором оценок.

Единственное решение, которое определяет максимальную отдачу от вложенных средств и качество интеграции LLM, — это то, какую модель вы используете. Общий рефлекс — «выбрать самую сильную модель»; Однако зачастую это означает ненужные затраты и задержки. Правильный подход — выбрать самую легкую модель, которая справляется с каждой задачей, и основывать этот выбор на измерениях, а не на догадках. В этом модуле вы сравните семейство моделей по оси возможности/скорости/затрат, определите стратегию маршрутизации модели в соответствии со сложностью задачи и подтвердите свой выбор с помощью небольшого набора оценок.

Понимание модельного семейства

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

класс

пример

талант

скорость

Стоимость

Доступные задачи

быстро

Хайку 4.5

средний

очень высокий

низкий

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

сбалансированный

сонет 5

высокий

высокий

средний

Общее назначение, кодирование, многоэтапный поток, большая часть работы агента

сильный

Опус 4.8

самый высокий

средний

высокий

Сложные рассуждения, долгосрочные автономные задачи, сложный анализ

Критический вывод: более мощная модель не справляется лучше со всеми задачами. При простой маркировке «срочно или нет» сильная модель и быстрая модель дают один и тот же правильный ответ; разница лишь в том, что мощный стоит в 5 раз дороже и медленнее. Дополнительный талант приносит пользу только тогда, когда этого требует миссия.

Шаг за шагом: как выбрать модель?

  1. Классифицируйте задачу. Является ли оно рутинным/шаблонным (маркировка, вывод) или открытым/многоэтапным (анализ, планирование, кодирование)?
  2. Начните с самого легкого кандидата. Попробуйте это с быстрой моделью. Если этого достаточно, остановись.
  3. Если этого недостаточно, переходите в более высокий класс. Если точность низкая, переходите к сбалансированному, если этого недостаточно, переходите к сильному.
  4. Измерьте, а не гадайте. Сравните точность и стоимость каждого кандидата с небольшим набором оценок (ниже).
  5. Настройте перенаправление. Вместо подключения к одной модели распределите задачу на нужную модель с помощью «роутера».

Модель маршрутизации

Реальные рабочие нагрузки смешанные: большинство входящих запросов простые, некоторые сложные. Отправлять их всех на мощную модель — напрасная трата; Отправка их всех в быструю модель снижает качество. Эту проблему решает маршрутизация: дешевая модель (или простое правило) сначала классифицирует задачу, затем задание переходит к соответствующей модели.

# Подсказка маршрутизатора (работает с дешевой моделью) Классифицируйте входящий запрос по его сложности. Возвращайте только следующий JSON:{"difficulty": "simple|complex"}Простой: одноэтапный, шаблонный, короткий ответ.Сложный: требует многоэтапного рассуждения, анализа или длительного генерирования.Запрос: """{{request}}"""

  • перейти к простой → быстрой модели (дешево, быстро).
  • переходим к сложной → мощной модели (дорого, но нужно).

Этот шаблон значительно снижает среднюю стоимость, поскольку большая часть трафика, как правило, проста.

Совет: для принятия решения о направлении не всегда требуется степень LLM. Простые правила, такие как «Перейти к быстрой модели, если текст меньше 20 слов», также являются руководством и не требуют дополнительных затрат токенов. Сначала попробуйте правило.

Связь выбора с доказательствами: небольшой кластер оценки

Не выбирайте модель по принципу «мне она кажется лучше». Eval (оценочный набор) — небольшой набор образцов, для которых известен правильный ответ; вы запускаете каждую модель в этом наборе и измеряете точность, стоимость и задержку.

# Шаблон настройки оценки1) Соберите 20-50 реальных примеров, напишите от руки «правильный ответ» на каждом. 2) Запустите каждую модель (быструю/сбалансированную/сильную) на этом наборе. 3) Для каждой модели: количество правильных значений, среднюю пропускную способность жетонов, стоимость запроса, среднее время. 4) Выберите модель, которая «даёт достаточную точность и дешевле всего».

# Таблица сравнения оценок (заполнение) Модель | Точность | Стоимость за запрос | Средняя продолжительностьHaiku | ...% | ... $ | ... snSonnet | ...% | ... $ | ... снопус | ...% | ... $ | ...сек

Слабая подсказка/Сильная подсказка (решение о выборе модели)

# СЛАБАЯ (нет оснований для принятия решения). Давайте использовать лучшую модель, бюджет не важен.

# STRONG (решение на основе измерений) При оценке 50 образцов Haiku дал точность 96%, Sonnet дал точность 97%; Разница статистически незначима. Выбор пал на Haiku, потому что он в 5 раз дешевле и в 2 раза быстрее. Если точность упадет ниже 95%, решение об обновлении до Sonnet будет принято автоматически.

Мощная версия; привязывает выбор к числу, порогу и правилу эскалации. Это одновременно защищает сегодняшнее решение и управляет будущими изменениями.

Три мини-кейса

Случай 1. Бегство от подавляющей модели. Колл-центр готовил сводки всех разговоров с Opus; ежемесячный счет был высоким. При оценке 40 образцов Sonnet отставал от Opus на 1% по точности, но стоил одну треть. Краткое содержание перенесли в Сонет; ежемесячная стоимость снизилась с 9000 до 3100 долларов США, претензий к качеству не было.

Случай 2 — Смешанный трафик с перенаправлением. 80 % запросов группы технических специалистов по юридическим вопросам касались простой маркировки документов, 20 % — сложного анализа контрактов. Они отправили их всех к мощной модели. Они добавили дешевый маршрутизатор и распределили простые задания в Haiku, а сложные — в Opus; средняя стоимость запроса снизилась на 64% при сохранении качества анализа.

Случай 3 — Стоимость сокращения без измерения. Чтобы снизить затраты, одна команда сократила сложное извлечение медицинского кода непосредственно до быстрой модели; Они не оценивали. В реальном времени точность упала с 92% до 78%, что привело к возврату неверных выводов. Сначала им нужно было провести оценку: для этой задачи требовалась мощная модель. Урок: и уменьшение, и подъем выполняются путем измерения.

Распространенные ошибки

  • Рефлекс «самой сильной модели»: растрата и ненужная задержка при выполнении простых задач.
  • Изменение модели без измерения: без оценки рискованно как сокращение, так и расширение.
  • Привязка к единой модели: маршрутизация в смешанном трафике часто более эффективна.
  • Всегда путайте маршрутизатор с LLM: простые правила могут работать без затрат.
  • Не устанавливать порог повышения: что произойдет, если точность упадет, следует определить заранее.
  • Не исправлять версию модели: запишите, над какой моделью/версией вы работаете в производстве; Изменение версии может изменить поведение.

Глубже: сохранение оценки и постепенное испытание

Выбор модели – это не единовременное решение. Провайдеры вводят новые модели, меняются цены, меняется ваша должностная инструкция. Так что настройте кластер eval один раз и не забудьте; держи его как живое существо. Когда выходит новая модель, вы пропускаете через нее те же 20-50 образцов, обновляете таблицу и снова принимаете решение. Это защитит вас от ловушки «интуиции переключения паттернов».

Второй продвинутый метод — это резервный/каскадный паттерн. Сначала вы даете задание дешевой модели; Если выходные данные имеют низкую достоверность или уровень проверки (блок 11) отклоняет их, вы передаете тот же запрос на эскалацию. Таким образом, большая часть трафика распределяется по дешевой модели, и лишь оставшаяся часть трафика направляется на дорогую модель. Это и дешевле, и надежнее, чем фиксированный подход с использованием одной модели.

Третий момент заключается в том, что оценка включает в себя не только точность, но также стоимость и задержку. Если модель на 1% точнее, но в 3 раза дороже и в 2 раза медленнее, для большинства работ такой компромисс не стоит того. Примите решение по трем осям (точность, стоимость, задержка) и определите «порог достаточности»: «если точность выше 95%, выбирайте самый дешевый».

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

Еще одно предостережение: кластер eval должен отражать вашу фактическую рабочую нагрузку. Оценка, состоящая только из простых примеров, скрывает места, где модель спотыкается в сложных случаях, и внушает вам ложную уверенность. Хорошая оценка; Он включает в себя как простые примеры, так и необычные случаи, с которыми вы сталкиваетесь в реальности (неоднозначные, неполные, противоречивые данные). Это трудное меньшинство определяет ваш выбор модели, потому что каждая модель в любом случае преуспевает в легком большинстве. Поддерживайте актуальность и репрезентативность вашего Eval, периодически добавляя в него новые реальные примеры.

В заключение

Правильная модель — это самая легкая модель, которая справляется со своей задачей; Более мощный не означает лучший в каждой работе, это просто дороже и медленнее. Классификация задачи и старт с самого лёгкого кандидата, распределение смешанного трафика с маршрутизацией и обоснование выбора небольшим набором eval’ов многократно снижает стоимость при сохранении качества.

Задача приложения

Выберите рабочую нагрузку. (1) Классифицируйте задачу как простую/сложную. (2) Разработайте небольшой оценочный набор из 20 реальных примеров (с правильными ответами). (3) Составьте план заполнения таблицы сравнения точности/затрат/времени для трех классов моделей. (4) Если у вас смешанный трафик, напишите правило маршрутизации и установите порог эскалации.

контрольный список

  • [ ] Я могу сравнить семейство моделей по оси возможности/скорость/стоимость.
  • [ ] Я могу применить принцип «самой легкой успешной модели».
  • [ ] Я могу настроить маршрутизацию модели в зависимости от сложности задачи.
  • [ ] С помощью небольшого набора eval я могу связать выборку с доказательствами.
  • [ ] Я могу определить порог повышения/понижения.