Ваш счет за ИИ — это не проблема модели. Это проблема архитектуры.

Если ваши расходы на LLM растут, вы, скорее всего, захотите перейти на более дешевую модель. Например, с GPT-4 на GPT-4-mini. Это немного поможет, но редко решает реальную проблему.

Реальная проблема заключается в вашем рабочем процессе. Большинство людей пропускает каждый этап через LLM. Они используют языковые рассуждения для задач, в которых они не требуются.

Любой рабочий процесс ИИ состоит из четырех частей:

• Триггер: запускает работу. Стоимость близка к нулю. • Детерминированное ML: классифицирует или оценивает данные. Это дешево. • LLM: читает, пишет и рассуждает. Это дорого. • Инструмент/API: извлекает или записывает данные. Это дешево.

Разрыв между детерминированным ML и LLM огромен. LLM может стоить в 100–1000 раз дороже простого классификатора. Если вы не выбираете правильный инструмент для каждого этапа, вы по умолчанию используете самый дорогой.

Рассмотрим систему обработки заявок в службу поддержки.

Плохая реализация отправляет всю заявку в LLM. Она просит LLM классифицировать намерение, направить заявку, составить черновик ответа и обновить CRM. Это неоправданно дорого. Для классификации не нужна LLM. Нужна простая модель, которая сопоставляет текст с категорией.

Более эффективная реализация выглядит так:

  1. Триггер: поступает заявка.
  2. Детерминированное ML: быстрая и дешевая модель определяет, является ли заявка вопросом оплаты, технической проблемой или спамом.
  3. LLM: используется только для составления черновика ответа по валидным заявкам.
  4. Инструмент/API: система обновляет CRM.

В этом варианте спам-заявки никогда не доходят до LLM. Вы перестаете платить «налог на LLM» за бесполезные задачи.

Если вы правильно выстроите архитектуру, вы исключите самые дорогие вызовы еще до того, как начнете менять модели.

Следуйте этим шагам, чтобы снизить свои расходы:

  • Опишите свой рабочий процесс. Определите, какие этапы требуют реальных рассуждений, а какие являются просто классификацией или извлечением данных.
  • Вынесите детерминированные шаги за пределы промпта. Используйте более быстрые и дешевые методы для маршрутизации и оценки.
  • Установите «шлюз» для LLM. Не генерируйте ответы для задач, которые в них не нуждаются.
  • Оценивайте размер модели в последнюю очередь. Выбирайте модель поменьше для этапа генерации только после того, как ваша архитектура станет максимально оптимизированной.

Хватит спорить о том, какая модель дешевле за токен. Начните строить архитектуры, которые используют дорогой «движок» только тогда, когда это действительно необходимо.

Источник: https://dev.to/bakshiyogesh/your-ai-bill-isnt-a-model-problem-its-an-architecture-problem-1ole

Дополнительное обучающее сообщество: https://t.me/GyaanSetuAi