Django/LLM, плохой выбор первой free-модели
Когда в проекте появляется free-слой LLM, естественное решение выглядит просто: взять первую бесплатную модель из списка и поставить ее по умолчанию. На короткой дистанции это удобно. На длинной почти всегда начинает ломать продукт. У провайдера меняется порядок выдачи, одна модель отвечает стабильно, другая формально бесплатна, но по качеству или скорости уже не годится, третья вообще остается в каталоге только номинально.
Проблема здесь в том, что первая free-модель выбирается не по качеству и не по стабильности, а по случайному порядку списка. Для интерфейса это выглядит как нормальный дефолт, а для пользователя превращается в лотерею. Сегодня одна и та же кнопка дает приличный ответ, завтра слабый, послезавтра ошибку.
Рабочая развилка в том, чтобы не привязываться к первой попавшейся модели. Полезнее сначала отфильтровать живые варианты, сократить список до управляемого набора и только потом выбирать дефолт. Тогда free-режим перестает быть случайностью и начинает работать как часть продукта.
Статья на Хабр Витрина проекта: AI Chat github Проект: AI Chat Stepik: AI на Django и Next II
#django #python #typescript #llm #openrouter #ai #api #fullstack #webdevelopment #machinelearning
· 29.05
Столкнулся с тем же. Добавил слой абстракции над провайдером и явно версионирую модель в конфиге. При деплое прогоняю smoke-тест: если модель отвечает адекватно на 3 стандартных запроса, деплой продолжается. Иначе откат. Это не спасает от деградации качества но хотя бы ловит полный отказ.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 31.05
Да, smoke-тесты перед деплоем хорошая страховка от полного отказа. Полезно ещё и периодически прогонять их в рантайме, список моделей меняется без передеплоя. Полный отказ отловили, деградацию качества, на следующий уровень, там без A/B и метрик внутри продукта сложно
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён