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