Оптимизация стоимости
Last updated
Was this helpful?
Last updated
Was this helpful?
Один из распространенных вопросов: "как рассчитать стоимость диалога, и от чего она зависит?". В данной статье подробно расскажем как управлять стоимостью и оптимизировать ее.
Средняя стоимость полноценного диалога внутри платформы по всем учетным записям варьируется от 10 до 20 руб. за диалог.
Это значит, что есть клиенты, у которых средняя стоимость диалога равно 4 рублям, а есть те, у которых средняя стоимость 1 диалога равна 30 рублям.
Различия происходят от причин. У одних пользователей может быть небольшая база знаний, небольшой промт инструкции и отсутствуют какие-либо специфические функции типа таблиц и пр. А у других построены сложные системы с большим количеством функий и т.д.
Давайте рассмотрим это подробнее.
Стоимость ответов ботов на платформе Савви, как и любых систем, построенных на базе LLM зависит от объема символов, передаваемых в модель. При этом важно учитывать, что сообщения от клиента имеют стоимость на порядок выше, чем сообщения полученные от бота/нейросети:
Это происходит из-за того, что мы отправляем в модель гораздо больше символов, чем получаем от нее, а именно, мы отправляем:
Сообщение клиента
Системный промт/инструкцию бота
Функции, которые созданы внутри бота:
таблицы,
подчиненные боты,
элементы базы знаний,
элементы работы с СРМ-системами (чтение полей, запись полей и пр.)
Все эти элементы содержат в себе определенный формат - название функции, ее описание, структура функции в JSON и пр., т.е. данные в виде символов, которые мы должны передавать, чтобы модель понимала контекст этих функций и могла их правильно использовать.
Информацию, полученную при вызове функции (базы знаний, таблицы и пр.) - чтобы подать ее в модель и она могла это обработать.
Историю диалога - чтобы бот понимал контекст и не терялся.
Историю вызова функций - чтобы бот не запрашивал одни и те же функции несколько раз.
В результате мы получаем большой объем данных, которые мы передаем в модель и которые она должна переработать, а иногда и не один раз.
Например, если модель осуществляет поиск в таблице, и не находит ответ, она может запустить поиск снова, но с другими параметрами, при этом для модели это два разных вызова, где в первом получен какой-то результат, и с этим результатом она заходит на второй круг.
А теперь представьте, что это какой-то сложный обмен, с какой-то системой, например, YCLIENTS, где только функций для обмена с системой более 10. Стоимость кратно возрастает.
НО решения есть, о них ниже.
Рассмотрим несколько основных способов оптимизации стоимость ответов от Савви.
Сокращать историю диалога имеет смысл, когда диалог с клиентом происходит на регулярной основе. Например, в салонах красоты клиентская база во многом состоит из постоянных клиентов, которые обращаются на канал коммуникации (например, WhatsApp) с определенной периодичностью, например, раз в две недели.
В этом случае нет смысла передавать всю историю диалога в контекст для модели, т.к. диалог в этом случае может быть очень длинным, и повторяющим одни и те же контексты. В результате и модель будет путаться и стоимость будет высокой.
В этих случаях, можно использовать обрезку истории при помощи настройки передачи истории сообщений, которая находится в настройках бота в разделе Дополнительно:
Тут существует несколько вариантов:
Передавать историю за X минут. В том случае, можно указать количество минут, в течение которых бот будет помнить историю сообщений.
Передавать историю за X сообщений. В этом случае, можно указать количество сообщений в диалоге, за которые бот будет помнить историю диалога.
Например, если речь идет о повторяющихся обращениях, что характерно при работе с YCLIENTS / Altegio, можно выбирать первый вариант - ограничение по количеству минут.
Если речь идет о каких-то сервисных ботах, для внутренней базы знаний, например, подключенных через Telegram-ботов, то тут можно ставить ограничение по количеству сообщений (хотя вариант по времени тут тоже подходит).
Еще одна полезная функция, которая влияет на стоимость - Сохранять историю вызова функций.
Данная настройка так же находится в дополнительных настройках бота:
Данная настройка определяет необходимость передачи в модель при каждом вызове предыдущие вызовы функций. Сохранение предыдущих вызовов может быть полезно, когда мы получаем какую-то информацию, которая может быть нам полезна в будущем.
Например, клиент спросил: "Когда будет доставка по номеру заказа 12345". Модель обращается в СРМ и получает всю информацию по заказу, например, в таком виде:
Номер заказа: 12345
Дата сборки заказа: 24.12.2024
Дата поступления в пункт для отправки: 25.12.2024
Дата доставки: -
Состав заказа: Джинсы Levis, футболка TH, майка CC.
Бот может ответить так: "Срок доставки пока не определен, но ваш заказ уже собран".
Если клиент начинает уточнять: "Но хотя бы примерно?"
Бот может ответить так: "Вижу, что ваш заказ уже поступил в пункт для отправления, скоро мы получим дату доставки и свяжемся с вами". При этом ему не пришлось снова отправлять запрос в СРМ для получения информации по заказу.
При этом, если диалог строится таким образом, что внутри самого диалога есть вся информация по предыдущим результатам вызванных функций, то можно эту функцию отключить и таким образом на длинных диалогах стоимость будет ниже за счет того, что не будут передаваться ранее вызванные функции.
Как это работает рассмотрим на примере ниже:
Представим, что у компании 10 различных прайсов, которые хранятся в Excel-таблицах.
Если мы загрузим все таблицы в одного бота, то мы получим 10 разных функций, каждая со своим описанием, инструкцией и пр.
Минус в том, что мы, таким образом, сразу сильно перегружаем контекст бота информацией, которую он должен держать в памяти, во-вторых, сразу кратно увеличиваем стоимость диалога, т.к. каждая функция передается при каждом обращении к модели.
Мы можем здесь сделать иначе:
Загрузить все таблицы в этого подчиненного бота
Получается, что весь объем функций-таблиц будет содержаться во втором боте, а в первом у нас будет только одна функция названная "Прайсы", соответственно мы в 10 раз сократим описание функций.
Решение в выносе определенных кусков в отдельных ботов. В выше описанном примере можно было бы сделать отдельного бота, в которого подключить все таблицы, таким образом вместо 10 функций иметь только одну у главного бота. А в случае, если клиент запрашивает прайс уже вызывать подчиненного бота с 10 функциями - таблицами. Но это все равно будет дешевле, т.к. не будет передавать все функции-таблицы при каждом вызове.
Последний способ - это контроль того, что возвращает бот при вызове базы знаний, таблиц и других функций.
Когда вы используете интеграцию с amoCRM или Битрикс24 вы можете использовать функционал по чтению полей сделки и контрагента, а так же записи в них. Каждое поле - это дополнительная информация в соответствующей функции, поэтому чем больше полей вы выбираете, тем дороже диалог. Старайтесь выбирать только те поля, которые действительно необходимы.
Не всегда очевидный, но крайне эффективный способ - использование в основной инструкции английского языка вместо русского. Как правило русский язык стоит в 3-4 раза дороже, т.к. в русском языке токен (символ) соответствует 1 букве, а иногда на одну букву, например, букву Ы будет приходиться 2 токена. В сравнении с этим, в английском языке 1 токен может соответствовать целому слову, что в свою очередь обходится дешевле.
Еще один довольно очевидный и действенный способ - это внимательно смотреть, а какой объем информации вам возвращают вызванные ботом функции. Насколько весь объем нужен вам? Нельзя ли его разбить на смысловые куски? Обязательна ли это информация?
Рассмотрим на конкретных примерах.
Часто бывает так, что при обращениям к таблице мы можем получить из нее большой объем информации, что как уже очевидно - ведет к увеличению объема обрабатываемого контекста и соответственно стоимости.
Для примера с таблицей важно при запросе сразу сужать поиск, чтобы получать только то, что необходимо.
Если сузить поиск на уровне обращения клиента невозможно, то можно использовать оператор LIMIT при запросе к таблице, и определить максимальный объем запрашиваемых данных.
Сокращение объема при работе с типовыми CRM
В данном случае, имеется ввиду работа с amoCRM и Битрикс24, с которыми имеется возможность получать данные из полей сделки, контакта и записывать туда информацию.
Чем больше полей мы выберем для запроса или записи, тем больше длина функции, которая за это отвечает.
Про мультиагентность и подчиненных ботов у нас есть отдельный , где можно подробно ознакомиться с тем, как работает такая система делегирования одним ботов и передача определенных данных другим, но основной смысл в том, что мы можем выделять целые блоки инструкции и функций в отдельных изолированных ботов.
Создать подчиненного бота (как это делается смотрите в соответствующем )
Например, при работе с таблицами, получим результат, мы можем получить большой объем данных, например 20 строк с какой-то информацией. Чем больше информации - тем дороже ответ. Поэтому можно заранее предусмотреть какие-то вопросы, которые могут сузить поиск в таблице и находить более конкретную информацию. Если так сделать исходя из сценария диалога сделать не получается, то можно ограничивать получаемую информацию из таблицы используя оператор LIMIT. Подробнее об этом описано в .
Если говорить о базе знаний и работе с блоком , то тут решение еще проще - не создавайте файлы с большим текстом, разбивайте его на более мелкие смысловые файлы.
Подробно о работе с таблицами описано в отдельном .
