Как выбрать модель под задачу и не разориться

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

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

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

Почему вопрос «какая модель лучше» неправильный

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

Модель в системе - не сотрудник, которого нанимают «самого умного на рынке». Это деталь на конкретном месте, и у места есть требования. Верхняя строчка рейтинга не отвечает ни на один из них.

Правильный вопрос звучит так: какая модель нужна вот на этом шаге и почему. И ответ на него почти никогда не одинаковый для всей системы.

flowchart LR
  A[Поток входящих материалов] --> B[Роль: массовое чтение и первичный отбор]
  B -->|быстрая дешевая модель| C[Короткий список]
  C --> D[Роль: рассуждение, редактура, перевод]
  D -->|сильная модель| E[Готовый результат]
  F[Отраслевая база знаний на русском] --> G[Роль: поиск по смыслу]
  G -->|модель отечественного провайдера, своя квота| D

Роли, а не рейтинги: как это устроено у меня

В моей системе несколько ролей, и у каждой своя модель.

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

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

Три параметра, по которым реально выбирают

Первый: язык и домен

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

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

Второй: характер задачи

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

Значит, вывод «модель слабая» неверен. Верный вывод: эта модель хороша на отборе и не годится на генерации. Она остается в системе, просто на своем месте.

Третий: способ оплаты

Обычная схема - поштучная оплата за токены. Токен - это кусочек текста, примерно часть слова; платите вы и за то, что отправили модели, и за то, что она написала в ответ. При такой схеме стоимость растет вместе с объемом, линейно и без потолка.

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

flowchart TB
  A[Регулярный вызов, который на самом деле не нужен] --> B[Шаг 1: перевести на модель дешевле]
  A --> C[Шаг 1: проверить, нужен ли вызов вообще]
  B --> D[Расход по вызову меньше в 7 раз]
  C --> E[Вызов отключен, расход по нему исчез]
  D --> F[Силы потрачены на оптимизацию мусора]
  E --> G[Сначала нужность, потом цена]

Ловушка удешевления

Теперь про ошибку, которую я проверила на себе.

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

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

Потолок токенов, который вы не тратите

При вызове модели вы задаете верхнюю границу длины ответа - параметр, который обычно называется max_tokens. Это не расход, это заявка: «ответ может быть вот таким длинным».

У провайдеров бывает проверка платежеспособности по запрошенному потолку, а не по фактическому расходу. Задача, которая просит потолок модели ради ответа в девяносто токенов, начинает падать при просевшем балансе - притом что тратит она копейки. Симптом обманчивый: расход маленький, а вызовы не проходят. Лечится тем, что потолок ставится по реальной длине ответа, а не «побольше, вдруг пригодится».

Один ключ на всех

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

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