Модели и проекты
Одной огромной моделью забивают все маленькие гвозди.
Почему «поставим самую умную» быстро превращается в медленный и дорогой продукт, и как разделить задачи без зоопарка интеграций.
В продукте появилась первая AI-функция. Разработчик выбрал самую сильную модель из доступных: меньше риска, быстрее показать результат. Потом той же моделью начали определять тему обращения, сокращать заголовки и раскладывать письма по трём папкам.
Теперь сортировка слова «возврат» требует вычислительной машины с характером профессора. Работает отлично. Только медленно и зачем-то дорого.
01
Самая сильная модель годится для первого запуска
На старте важнее проверить саму функцию. Одна модель, один ключ, минимум настроек. Если идея не нужна людям, тонкая оптимизация расходов её не спасёт. Поэтому начинать с сильного варианта вполне разумно.
Проблема начинается позже, когда временный выбор становится архитектурой. Появляются новые задачи, но каждая наследует старую модель просто потому, что её идентификатор уже записан в настройках. Через месяц никто не помнит, почему классификатор писем работает тем же способом, что и сложный анализ документа.
02
Назовите работу до выбора модели
«Нам нужен AI» не описывает задачу. Извлечь номер заказа, написать ответ клиенту, проверить договор и спланировать десять действий агента требуют разного качества, контекста и времени.
Простую массовую операцию разумно начинать с быстрой недорогой модели. Сложную проверку можно отдать более сильной. Если ошибка критична, добавляют проверку правилом или человеком, а не надеются, что ещё более дорогой ответ внезапно станет договором с печатью.
Модель выбирают не для проекта вообще. Её выбирают для одной повторяемой работы внутри проекта.
03
Бенчмарк из интернета не знает ваших пользователей
Общий рейтинг полезен, чтобы составить короткий список. Победителя он не назначает. Модель может хорошо решать олимпиадные задачи и плохо возвращать ваш короткий JSON. Может писать убедительно, но регулярно забывать одно поле из пяти.
Соберите реальные примеры и проверьте кандидатов на одном наборе. Для классификации считайте правильные категории. Для извлечения сверяйте поля. Для поддержки отмечайте, решён ли вопрос и не появилось ли обещание, которого компания не давала. Затем сравните задержку и цену законченной работы.
04
Несколько моделей не должны превращаться в несколько интеграций
Плохой способ: в каждом сервисе хранить отдельный ключ провайдера, отдельный адрес и собственную таблицу цен. Через пару замен моделей никто уже не уверен, какой компонент куда ходит и кто оплачивает забытый эксперимент.
Удобнее оставить единый API-слой, а модели разделить по проектам, пресетам или рабочим сценариям. Поддержка получает свой ключ и лимит. Каталог и внутренний помощник получают свои. Замена модели не требует переписывать остальные продукты.
05
Резервная модель нужна не всегда
Если основной маршрут временно недоступен, резерв может сохранить функцию. Но без правил он меняет поведение продукта в самый неудобный момент. Другая модель иначе следует формату, по-другому считает контекст и может стоить больше.
Для простого текста переключение допустимо. Для строгого извлечения или действия с последствиями лучше остановиться и показать понятную ошибку, если резерв не прошёл тот же тест. Отказ иногда дешевле очень уверенной самодеятельности.
Как разделить это в TokenTool
Каталог показывает доступные модели, контекст и текущие тарифные поля. В Playground кандидатов можно сравнить на одинаковом вопросе. Проекты, пресеты и отдельные ключи разделяют функции, расходы и лимиты без набора разных провайдерских интеграций.
Начните с двух маршрутов: массовый простой и редкий сложный. Больше добавляйте только тогда, когда логи показывают понятную причину. Зоопарк моделей тоже ест деньги, просто в другом отделе.