Вопрос «какую модель взять» звучит первым, а решаться должен третьим. Сначала — где могут находиться данные, потом — какая задача, и только потом выбор конкретной модели. Если сделать наоборот, легко построить решение на сервисе, который не пройдёт согласование в вашей же службе безопасности. Разберём, как выбирать по существу.
Мы сознательно не приводим здесь таблицу с баллами моделей по тестам. Такие таблицы устаревают за месяцы, а главное — качество на публичных тестах слабо предсказывает качество на вашей задаче. Ниже — способ выбрать, а не готовый ответ.
Сначала: где могут находиться данные
Этот вопрос отсекает большую часть вариантов и потому идёт первым. Если в задаче есть персональные данные россиян или коммерческая тайна, зарубежные облачные сервисы отпадают, и обсуждать их бессмысленно. Остаются российские облачные модели и открытые модели, развёрнутые у вас.
Ответ на этот вопрос даёт не разработчик и не руководитель проекта, а служба безопасности — и получить его надо до, а не после выбора технологии. Переезд из облака в закрытый контур на позднем этапе означает смену модели, повторные замеры качества и переработку промптов.
Российские облачные модели
Крупные российские провайдеры предлагают языковые модели по API с размещением внутри страны. Это закрывает вопрос локализации и снимает с вас инфраструктуру.
Что здесь хорошо
- Старт занимает дни, а не недели: ни закупки, ни развёртывания.
- Локализация соблюдена, есть договор с обработчиком — согласование обычно проходит.
- Русский язык для этих моделей родной, а не выученный по остаточному принципу.
- Плата по факту использования: на малых объёмах это дешевле любой собственной инфраструктуры.
Что здесь плохо
- Данные всё-таки покидают ваш периметр — для части задач этого достаточно, чтобы вариант отпал.
- Вы зависите от провайдера: изменение цен, лимитов или самой модели произойдёт без вашего участия.
- Модель может обновиться, и поведение изменится. Промпты, отлаженные месяц назад, придётся перепроверять.
- На больших объёмах плата за запросы растёт линейно и в какой-то момент превышает стоимость своего железа.
Открытые модели в своём контуре
Открытая модель разворачивается на вашем оборудовании. Данные не уходят никуда, поведение не меняется без вашего решения, стоимость запроса после закупки железа стремится к стоимости электричества.
Что здесь хорошо
- Данные физически не покидают периметр — это снимает целый класс вопросов у безопасности.
- Версия модели фиксирована: она не обновится сама и не изменит поведение посреди рабочего дня.
- На большом объёме запросов дешевле облака, и разница растёт с масштабом.
- Модель можно дообучить на своих данных, не выгружая их наружу.
Что здесь плохо
- Нужны GPU, а это закупка, размещение и эксплуатация. Для крупных моделей это серьёзные деньги.
- Нужны люди, которые это поддерживают: обновления, мониторинг, восстановление после сбоев.
- Качество лучших открытых моделей на сложных рассуждениях обычно уступает лучшим закрытым — на узких задачах разница часто незаметна, на широких заметна.
- Стартовать дольше: от закупки до работающего сервиса проходят недели.
У нас есть проект, где выбор был именно таким и решился в пользу своего контура: заказчику требовалась генерация кода, а выгружать кодовую базу наружу было запрещено. Модель развернули внутри — типовой код стал писаться в пять раз быстрее, при этом ни одна строка не ушла за периметр.
Как выбирать по задаче
Задача узкая и повторяющаяся
Классификация обращений, извлечение полей из документов, ответы по базе знаний. Здесь разница между моделями невелика: правильно поставленная задача важнее выбора модели. Берите то, что проходит по безопасности и дешевле в эксплуатации, — и не переплачивайте за возможности, которые не используете.
Задача требует рассуждения
Разбор сложного договора, анализ противоречий, многошаговое планирование. Здесь разница между моделями существенна, и экономия на модели оборачивается плохими ответами. Стоит закладывать более сильную модель хотя бы на самые ответственные шаги.
Задача — генерация текстов на русском
Российские модели здесь часто лучше по стилю: у них родной язык, а не выученный. Проверять это надо на своих текстах и своём тоне, а не на общих примерах, — расхождение бывает существенным в обе стороны.
Как проверить выбор за неделю
- Соберите набор из 50–100 реальных задач с эталонными ответами, подготовленными вашими специалистами. Это самая ценная часть работы, и обойти её нечем.
- Прогоните через каждую модель-кандидата с одинаковым промптом.
- Оцените ответы вслепую: проверяющий не должен знать, какая модель что выдала. Иначе сработает ожидание.
- Посчитайте стоимость каждого варианта на вашем реальном объёме запросов, а не на тестовом.
- Отдельно проверьте худшие случаи, а не средние: в эксплуатации решает не средний ответ, а самый плохой.
Разумная архитектура — не привязываться к одной модели. Если работа с моделью изолирована за собственным интерфейсом, замена провайдера становится задачей на дни, а не переписыванием решения. Это дешёвая страховка, и закладывать её стоит сразу.
Как считать стоимость и где ловушки
Сравнение по цене за тысячу токенов почти всегда вводит в заблуждение, потому что сравнивает не то, что вы будете платить. Реальная стоимость зависит от того, сколько текста уходит в каждый запрос, а это определяется задачей, а не тарифом.
Ловушка первая: длина контекста
В задачах с поиском по документам в модель уходит не только вопрос, но и найденные фрагменты — иногда несколько тысяч слов на каждый запрос. Разница между экономным и щедрым подбором фрагментов может дать пятикратную разницу в счёте при одинаковом качестве ответа.
Ловушка вторая: повторные запросы
Если решение проверяет ответ вторым обращением или переспрашивает при неудачном формате, реальное число запросов вдвое-втрое выше расчётного. Это надо закладывать сразу, а не обнаруживать по счёту за первый месяц.
Ловушка третья: рост объёма
Пилот на сотне запросов в день стоит копейки. При десяти тысячах запросов картина меняется, и точка, где своё железо становится выгоднее облака, может оказаться ближе, чем казалось. Считайте на планируемый объём, а не на текущий.
Практический приём: замеряйте стоимость на реальном наборе задач, а не по прайсу. Прогоните сотню типовых запросов, посмотрите фактическое потребление и умножьте на планируемый объём. Это занимает час и даёт цифру, которой можно верить.
Когда моделей нужно несколько
Распространённое заблуждение — что надо выбрать одну модель на всё решение. На практике разумнее разные модели на разные шаги, и это часто дешевле при лучшем качестве.
- Маленькая быстрая модель — на классификацию, маршрутизацию и определение намерения. Эти шаги случаются на каждом запросе, и экономия здесь заметна.
- Специализированная модель векторизации — на поиск. Она вообще не языковая и стоит несопоставимо дешевле.
- Сильная модель — только на финальную генерацию ответа, где качество действительно решает.
- Отдельная модель на проверку — там, где цена ошибки высока и оправдывает второй проход.
Такая архитектура даёт и экономию, и устойчивость: замена одного компонента не требует переделки остальных. Требование к реализации простое — работа с каждой моделью изолирована за своим интерфейсом.
Пять типичных ошибок выбора
- Выбирать по публичным рейтингам. Они мерят усреднённое качество на академических задачах, а вам нужно качество на вашей. Корреляция слабее, чем принято думать.
- Тестировать на десятке примеров. На такой выборке различима только грубая разница; всё интересное начинается на пятидесяти-ста реальных задачах.
- Оценивать ответы, зная, какая модель их выдала. Ожидание влияет на оценку сильнее, чем хочется признавать. Оценивать надо вслепую.
- Сравнивать по средней оценке, игнорируя худшие случаи. В эксплуатации репутацию решения определяет самый плохой ответ, а не средний.
- Выбрать модель до того, как согласована схема размещения данных. Самая частая и самая дорогая ошибка: решение строится, а потом не проходит согласование.
Что делать, когда модель обновилась
У облачных моделей есть свойство, которое редко учитывают: они меняются. Провайдер выпускает новую версию, поведение сдвигается, и промпты, отлаженные месяц назад, начинают работать иначе. Иногда лучше, иногда хуже — но всегда неожиданно.
Защита от этого простая и её стоит завести с первого дня: набор проверочных задач с эталонными ответами и регулярный прогон по нему. Тогда изменение поведения обнаруживается вами, а не пользователями. Если провайдер даёт возможность зафиксировать версию модели, ей стоит пользоваться и обновляться осознанно.
Для собственной модели в контуре этой проблемы нет — но появляется зеркальная. Модель не обновляется сама, и через год-полтора вы работаете на решении, которое заметно уступает доступным. Здесь нужен обратный процесс: регулярно проверять, не появилось ли что-то существенно лучше, и планировать переход как отдельную работу с замерами.
Что проверить у провайдера до подключения
Выбор модели — это ещё и выбор поставщика услуги, и здесь есть вопросы, которые лучше задать до, а не после интеграции.
- Используются ли ваши запросы для обучения моделей провайдера? Ответ должен быть в договоре, а не в маркетинговых материалах. Для корпоративных данных это принципиально.
- Где физически размещаются вычислительные мощности и хранятся ли запросы. Если хранятся — как долго и с какими мерами защиты.
- Есть ли возможность зафиксировать версию модели и как заранее уведомляют об обновлениях. Без этого поведение решения будет меняться неожиданно.
- Какие лимиты по числу запросов в единицу времени и что происходит при их превышении. Пиковая нагрузка не должна упираться в квоту.
- Каковы гарантии доступности и что предусмотрено при сбое. Для процессов, завязанных на ответ модели, это вопрос непрерывности бизнеса.
- Как оформляется договор и как проходит оплата. Звучит скучно ровно до момента, когда бухгалтерия не может провести платёж.
Отдельно стоит уточнить, что происходит с решением при прекращении договора: остаются ли у вас накопленные данные, история и настройки. Зависимость от провайдера — это не только техническая, но и организационная категория.
Как понять, что модель выбрана неправильно
Несколько признаков, по которым видно, что дело именно в выборе модели, а не в чём-то другом. Полезно знать их, чтобы не менять модель там, где это не поможет.
- Ответы правильные по сути, но неудачные по форме и тону. Это не повод менять модель — это задача для инструкции или дообучения формы.
- Модель не находит нужную информацию. Дело в поиске, а не в модели: смена генератора ответов ничего не изменит, если нужный фрагмент до него не доходит.
- Ответы разваливаются на сложных многошаговых вопросах, а на простых хороши. Вот это уже похоже на нехватку возможностей модели — стоит проверить более сильную на этом подмножестве задач.
- Модель систематически ошибается в терминологии вашей области. Может решаться и словарём в инструкции, и дообучением; смена модели помогает реже.
- Качество приемлемо, но стоимость или задержка не укладываются в требования. Здесь смена модели оправдана — но в сторону меньшей, а не большей.
Общее правило: прежде чем менять модель, разложите ошибки по причинам на своём проверочном наборе. В большинстве проектов, где мы это делали, доля ошибок, действительно связанных с возможностями модели, оказывалась меньше, чем доля ошибок поиска и постановки задачи.
Коротко
- Порядок решений: где могут лежать данные → какая задача → какая модель. Обратный порядок ведёт к переделке.
- Российские облачные модели выигрывают на скорости старта и малых объёмах, открытые в своём контуре — на защищённости и больших объёмах.
- На узких задачах разница между моделями невелика; на задачах с рассуждением она существенна.
- Выбор проверяется набором из 50–100 реальных задач и слепой оценкой, а не публичными рейтингами.
- Изолируйте работу с моделью за своим интерфейсом — это делает смену провайдера вопросом дней.