Не каждый endpoint нуждается в LLM
Не каждый endpoint нуждается в LLM
Иногда AI-фича в продукте выглядит как простая задача: взять запрос пользователя, отправить в модель, вернуть ответ.
Но в backend это почти никогда не просто один вызов API.
Как только фича попадает ближе к production, появляются скучные, но важные вопросы:
1. Что делаем, если модель отвечает 8 секунд? 2. Что возвращаем при timeout или деградации провайдера? 3. Как логируем запрос, не протащив лишние персональные данные? 4. Где граница между deterministic logic и вероятностным ответом? 5. Что кешируем, а что нельзя кешировать по смыслу? 6. Как объясняем пользователю, что результат может быть неточным? 7. Как откатить фичу, если модель начала вести себя нестабильно?
Для меня главный принцип простой:
LLM не должен становиться новым слоем бизнес-логики там, где достаточно обычного кода, правил, SQL, очереди или валидации.
Модель хорошо работает как помощник:
- классифицировать входящий текст;
- подготовить черновик;
- подсказать варианты;
- объяснить данные;
- ускорить ручной workflow.
Но если от ответа зависит деньги, безопасность, права пользователя или необратимое действие - вокруг модели нужна нормальная backend-архитектура: таймауты, fallback, retries, лимиты, аудит, ручная проверка и понятный rollback.
AI-фича становится production-фичей не тогда, когда модель дала красивый ответ. А когда система умеет безопасно пережить плохой ответ.
Как у вас в командах сейчас решают границу: где LLM уместен, а где лучше оставить обычную deterministic-логику?
