Speaker A
Аа так. Всем добрый день ещё раз. Приём, приём. Поставьте, пожалуйста, в чате, как меня видно, как слышно. Всё ли в порядке, всё ли, всё ли отлично.
Разбор промптов для AI-ботов в продажах: как правильно строить запросы и улучшать ответы ботов.
Key Takeaways
- Четкая структура промта снижает ошибки в ответах AI-бота.
- Излишняя детализация и водянистые формулировки могут ухудшить качество ответов.
- Конкретика и однозначность в промтах повышают точность и эффективность бота.
- Для сложных вычислительных задач лучше использовать отдельные специализированные боты.
- Объем промта влияет на стоимость и скорость ответа AI.
Summary
- Ведущий анализирует примеры промптов для AI-ботов, используемых в отделах продаж.
- Обсуждается важность четкой структуры промптов для уменьшения ошибок в ответах бота.
- Рассматривается кейс бота строительной компании с подробным разбором его промта и логики диалогов.
- Подчеркивается необходимость избегать излишне развернутых и водянистых формулировок в промтах.
- Обсуждается влияние объема информации в промте на качество и стоимость ответов бота.
- Ведущий советует использовать конкретику и однозначность в формулировках для повышения точности ответов.
- Отмечается, что для сложных задач, например расчетов, лучше использовать специализированные подчинённые боты.
- Поясняется, что разные модели ИИ могут по-разному реагировать на объем и структуру промтов.
- Вебинар включает интерактив с участниками, обсуждение их опыта и целей использования платформы.
- Демонстрируется работа с платформой для создания и настройки AI-ботов в мессенджерах.
Full Transcript — Download SRT & Markdown
Speaker A
Ага, всё супер, вижу. Если вдруг видео будет как-то подтормаживать, я включил тут максимальное качество, чтобы меня было хорошо видно. Если вдруг будет тормозить, то я поставлю среднее. Вот.
Speaker A
Но решил рискнуть. Думаю, интернет позволит хорошую картинку иметь. Вот поэтому, а, поэтому так. А сегодня у нас наш традиционный любимый, я бы сказал, формат разборов, где мы с вами берём примеры некоторых ботов, смотрим на их промты и разбираем,
Speaker A
что с ними так, что с ними не так. Это позволяет чуть глубже погрузиться в то, как эти промты должны строиться, как реагируют боты на них.
Speaker A
Мы прямо сегодня пробежимся по трём, по трём разным кейсам. А традиционно в начале я всегда люблю понимать, какая у нас аудитория сегодня участвует. Вот поэтому если у вас, э, есть возможность, пожалуйста, напишите, а вы от бизнеса или вы интегратор и уже были на этих
Speaker A
вебинарах или не были, работали с платформой, уже не работали. Ну, то есть немножко представьтесь, расскажите о себе, чтобы было понимание. Кто у нас сегодня участвует? Последнее время у нас участвовали большинство, было много интеграторов. Ну вот интересно, кто кто что делает, да?
Speaker A
Обычно где-то час максимум полтора в час. Угу. Хорошо. Хорошо. Тогда давайте с вами пробежимся традиционно по некоторым как бы азам.
Speaker A
Значит, во-первых, да, я сейчас подключу свой экран. Мне важно, чтобы вы тоже, значит, сказали, виден он у вас или не виден.
Speaker A
Значит, всё, я подключил демонстрацию. Это, пожалуйста, значит, э-э, значит, пожалуйста, да, подскажите, видно или нет?
Speaker A
Угу. Видно отлично. Да, большое всем спасибо за активность. Вижу, что много интеграторов. Вижу, что есть тот, кто от бизнеса внедряет для себя. Что важно сказать? что наша платформа - это платформа для создания, она называется, да, и это платформа для создания AI
Speaker A
ботов, то есть ботов на базе искусственного интеллекта. А и на текущий момент мы автоматизируем коммуникацию именно в, ну, каких-то в мессенджерах, то есть текстовую коммуникацию. А у нас есть, собственно, такой вот отдельный блок, который чатами, да, собственно, называется. И
Speaker A
здесь можно смотреть переписки бота с клиентами и самому осуществлять переписки внутри этого механизма. Есть отдельный раздел боты, где происходит настройка. Сегодня мы много времени уделим как раз этому разделу. Вот. А в данном случае мы сейчас будем разбирать, э, значит, кейс Романа, значит, Романа
Speaker A
Кузнецова. Роман, если вы здесь, то помашите ручкой в чате, поставьте где-нибудь там, не знаю, плюсик, ээ что, чтобы я видел, что вы здесь. Вот.
Speaker A
Значит, пока Роман пока Роман, а отписывает в чате, а я, соответственно, начну разбор и давайте откроем сразу этого бота, кликнем по нему и будем смотреть, что здесь происходит. Ну, как видно из названия, стройотдел, по всей видимости, это бот какой-то строительной
Speaker A
компании, а, или ремонтной компании, да, которая специализируется на ремонтных услугах. Ну и дальше видим промт. Этот промт здесь построен, ну, по ощущениям, по по как сказать, по почерку, да, он построен на базе вот этой сгенерированной инструкции. То есть у
Speaker A
нас есть возможность создавать инструкции автоматически на основе какой-то какого-то короткого описания. дальше эти инструкции как бы там корректировать в рамках, ну, как как нам это необходимо.
Speaker A
Базово, когда строится промт, всегда есть определённые разделы. А лучше иметь как бы чёткую структуру, потому что чем чётче структура, тем меньше ошибок будет у бота в ответах. Здесь, судя по структуре, со структурой всё в порядке, потому что есть роль, чётко обозначена.
Speaker A
Ты, Марина, профессиональный менеджер компании Строй отдел, ты эксперт в области продаж, специализирующий на ремонтных услугах. Дальше цели и задачи: презентовать компании её преимущество, выяснить потребности, пожелания клиента, ответить на вопросы клиента, помочь ему принять решение сотрудничества. Дальше приветствие, поприветствую клиента в
Speaker A
начале диалога. Язык ответов, отвечай на языке собеседника. Дальше есть много тут в стиле ответа. Ну, я так быстренько пробежался. Глобально тут придраться особо не к чему. А тут, конечно, надо смотреть, как это будет на тесте, потому что вообще, ну, есть такое правило, да,
Speaker A
что как бы ну, как это принято, да, когда ты общаешься с чат GPT, тебе нужно описать типа максимально подробно свой запрос, да, типа максимально вот как он возможен.
Speaker A
в случае построения как бы ботов, продавцов внутри платформы нашей, это правило, оно тоже с одной стороны как бы ну соответствует да действительности, но с другой стороны, нужно стараться, а, как бы, вот этот промт сильно не раздувать, то есть
Speaker A
сильно не расписывать какие-то вещи. Вот, например, здесь много в стиле ответа я вижу прямо вот много много много примеров всяких создано. То есть, скорее всего, это положительно влияет на ответы, что бот понимает, какие формулировки использовать можно, какие там, ну, прямо примеры потому что даны,
Speaker A
да но например спокойный сохраняя спокойный тон без давления, тут уже чуть много воды водянистой, да, то есть не очень понятно, как это как это интерпретировать. То есть или, например, там э ну поддерживать дружелюбный, живой, уверенный тон. Ну, вот это тоже
Speaker A
такая фраза, её как бы можно и не вставлять, на самом деле. И глобально кажется, что вот если мы вот эти две уберём строчки, то фундаментально ничего в общении, в ответах бота не поменяется.
Speaker A
Но при этом мы уменьшим как бы промт и за счёт этого уменьшения мы, во-первых, сократим сам объём этого промта, и у нас себестоимость, ну, и стоимость, собственно, будет ответа меньше.
Speaker A
Во-вторых, у нас здесь, возможно, он станет лучше отвечать, потому что чем меньше у него информации вот здесь, тем точнее он её соблюдает. Это не всегда как бы тоже не на всех примерах прямо как бы работает, потому что, например,
Speaker A
если мы используем там модель 4о и делаем какие-то расчёты, то она в этих расчётах может, ну, делать неверные значения. Например, для расчётов я бы использовал модели думающие, рассуждающие, вотнинг модели. Для их использования лучше использовать подчинённых ботов отдельно и в них
Speaker A
выносить отдельные вот эти задачки. Вот. Ну, обращайся на вы. О'кей. Проявляй эмпатию в начале диалога и давай твёрдые ответы. Ну, тоже такое, да, что такое твёрдые ответы. То есть это такое вот очень субъективное, да, грубо говоря, на один и тот же ответ два человека дадут
Speaker A
разные разное мнение. Твёрдый ответ или нетвёрдый. Когда есть очевидные какие-то, да, ну, совсем, но вот иногда где вот эта тонкая грань, непонятно.
Speaker A
Поэтому я как бы стараюсь, чтобы в промтах всегда было как бы конкре, ну, конкретика какая-то, да, вот чёткость, которую которая не имеет э двузначности, потому что там, где есть двузначность, там, скорее всего, будет какая-то вариативность ответа. Дальше. Так,
Speaker A
сейчас, извините, я проверю. А так, Роман. Ну, Романа по-прежнему не вижу. А, ну да ладно, а Роман посмотрит, если что, в записи. Значит, дальше смотрим шаги. Логика построения диалогов. Ну вот здесь тоже шагов как бы довольно много.
Speaker A
В целом по ним каких-то замечаний глобальных тоже нет. То есть поприветствуй клиента и кратко представь компанию строи отдел, её основную специализацию. Расскажи о компании строй отдел и её основных направлениях деятельности. Вызови функцию getext mission and values of the company. То
Speaker A
есть, ну, как бы миссия и ценности компании. Но м надо ли на втором шаге вот как бы это делать? Ну, не знаю. То есть здесь уже всё зависит от сценарии.
Speaker A
Если в этой компании так делают, то о'кей. А здесь у нас может быть, ну, какая-то хранится информация, да, которая как бы может быть там довольно объёмная. Задай вопросы клиенту для понимания его потребности. Тип объекта, квартира, дом, коммерческое помещение,
Speaker A
новостройка, вторичка. Это вот, кстати, неплохой такой вот пример, что если мы спрашиваем тип объекта, то да, нам нужны примеры, да, которые он должен спросить, потому что в его картине мира это могут быть там совершенно другой список. Потом площадь помещения, ког
Speaker A
начать ремонт, адрес объекта, название ЖК. То есть в целом, ну, неплохо структурировано. Единственное, здесь точки не хватает. Дальше. Расскажи об опыте компании на рынке. Более 7 лет, более 300 частных и двадцати коммерческих объектов. Вызови функцию getext. Ну и здесь вот идёт чек-лист.
Speaker A
Вот. Единственное, мне не нравится вот здесь вот эта двойная кавычка. Я бы избегал, наверное, вот таких таких ситуаций. То есть, если мы говорим про, ну, здесь вызывается файл базы знаний.
Speaker A
Если мы говорим про его вызов, то вот в названии файла базы знаний лучше вот такую штуку убирать. То есть вот лучше вот здесь их прямо убрать, эти кавычки, и здесь, соответственно, тоже их убрать, потому что, ну, бот и так поймёт, что
Speaker A
это вот этот чек-лист, просто эти кавычки, они где-то там чисто на программном уровне могут какую-то сыграть не очень хорошую штуку. Это точно так же, как вот здесь вот у Романа в целом база знаний собрана довольно чётко. Видимо, он присутствовал на
Speaker A
прошлых вебинарах и уже знает некоторые моменты, да, что, например, здесь мы не рекомендуем использовать вопросительную вопросительные формулировки. То есть, например, типа, ну, что здесь может быть?
Speaker A
Сколько стоит услуга, ремонт квартир и домов? То есть сколько стоит? Ну, это уже как бы подразумевает знак вопроса.
Speaker A
То есть вот здесь вот в этих названиях файлов знаков вопросов быть не должно, потому что если мы потом, ну, он начинает эти файлы как бы вызывать, он может на этом знаке вопросов просто вызвать неправильный файл. То есть вот
Speaker A
эти знаки припинания, они, ну, не очень хорошо, короче, здесь работают по лучше, поэтому лучше их избегать. Перечисля основные преимущества компании, вызови функцию getext.
Speaker A
Предложи клиенту возможность получить более детальную консультацию. Ответь на дополнительный вопрос. Клиент предложил следующие шаги. Попроси номер клиента для согласования схемы. Заполняя карточку клиента по мере поступления ответов в него. Когда клиент оставил номер, поставь задачу на ответственного менеджера, вызови функцию assign
Speaker A
manеджер. Ну, в целом вот как бы я бы так сказал, конечно, хотелось бы от Романа услышать типа в чём как бы есть проблема, потому что да, Роман, вот пока я тут рассказываю про ваш кейс, может быть, напишите, э, а что, собственно,
Speaker A
какие проблемы есть, потому что чисто визуально, ну, вот как бы как будто никаких проблем быть не должно. Ну, то есть чисто вот так вот, э-э, с первого взгляда всё, ну, структура самого промкта, она построена верно. Функции называются верно, там, где нужно, они
Speaker A
как бы вызываются. Опять же, вот, да, вот здесь тоже важный такой пример. Например, если клиент оставил номер телефона, вызови функцию там get fileтек, то есть мы в явном виде прописываем. И причём функция она называется вообще, ну, не так, как
Speaker A
подразумевается. То есть бот сам не поймёт, что ему нужно вызвать этот файл в случае, если оставил клиент номер телефона. Поэтому у Романа здесь правильным образом прописано, что делать в случае, если клиент оставил номер телефона. Опять же, если клиент написал
Speaker A
площадь помещения, вызови функцию, ну вот тут какие-то примеры, да, э примеры э внедрения объектов каких-то.
Speaker A
Ну, возможно, что-то другое имеется в виду. и возьми для примера несколько готовых объектов с аналогичной площадью.
Speaker A
При закрытии возражений клиента используй другую функцию. Вот. Ну, то есть клиент в мистексе, ну, тут и да, то есть потому что, ну, как в базе знаний боту отразить, что у клиента есть возражения? Возражений их может быть довольно много, и есть разные варианты.
Speaker A
Мы либо можем на каждое возражение сделать отдельный файл базы знаний, но, например, клиент говорит, что дорого, да, и мы можем просто создать файл базы знаний дорого и в него запихнуть конкретное возражение на слово дорого. А можем вот как у Романа в данном случае
Speaker A
сделать отдельный один файл для как бы всех вариантов возражения, да, и дальше, ну, на любое возражение вызывать этот как бы файл базы знаний, из него брать эту информацию. Ну, тут уже опять же нет тут правильного варианта. И тот, и
Speaker A
другой вариант, он правильный. Просто, ну, надо смотреть по тому, как это работает. Если работает стабильно, хорошо, оставляем так. Если видим какую-то нестабильность, разбиваем на каждое отдельное возражение. Если по стоимости этот вариант о'кей, ну, значит, о'кей. То есть здесь как бы
Speaker A
нет точного ответа, как делать. Здесь надо смотреть по ситуации. Ну, опять же, вот здесь в названии файла мне не нравятся вот эти скобочки. Я бы их как бы отсюда бы убрал и, соответственно, из файла бы тоже их бы убрал. Дальше идут
Speaker A
довольно обширный список, что запрещено у романа, у этого бота. И, ну, как бы о'кей, да, это нормально. То есть давать расширенную информацию по конкретным правилам. Причём здесь тоже правильным образом используется слово запрещено, потому что если использовать, например, не, то есть, например, не называй точные
Speaker A
цены, это будет работать хуже. Он может всё равно начать называть точные цены. когда мы пишем, что ему запрещено это делать, то как бы это прямо в явном виде однозначно даёт ему понимание, потому что с вот этими приставками, ну, точнее,
Speaker A
как это, что это будет приставка, да, наверно, ну, не приставка или предлог, наверное, не, э, не очень хорошо LLM модели работают. А, ну вот важное уточнение. Всегда подчёркиваю индивидуальный подход к каждому клиенту.
Speaker A
Ну, о'кей. То есть, возможно, в какой-то ситуации он может это подчеркнуть. А значит, сейчас посмотрю, написал ли что-нибудь Роман. Как можно оптимизировать стоимость цены за диалог?
Speaker A
О, вот мы пришли к этому вопросу. Ну, первый вариант оптимизации стоимости ответа за диалог - это перевести вот эту инструкцию на английский язык. То есть, если вы просто её переведёте на английский язык, уже стоимость соптимизируется. То есть она
Speaker A
сптимизируется, ну, на какие-то 10-15-20%. Это первое. Второе, надо смотреть вглубь файлов. То есть, что у вас вот здесь файлов. То есть меня конкретно вот здесь смущает такой объём вот этой как бы инструкции. То есть есть ощущение, что её бы можно было бы здесь как будто бы
Speaker A
подсократить, но не факт. Может и может и нельзя. То есть дальше надо смотреть, а что внутри файлов. Ну давайте вот, например, первый берём. Миссия и ценность компании, да? М где она? Так, сейчас.
Speaker A
Вот она, да? Смотрим этот файл. Ну вот, если посмотреть, то файл довольно как бы большой сам по себе, он довольно объёмный. Тут надо понять, а действительно ли в каждом диалоге вот такой объём требуется, да? Потому что как бы, ну, я, честно говоря, сторонник
Speaker A
вообще коротких ответов, то есть потому что люди, когда отвечают, ну, вот просто сотрудники, да, они всё-таки не часто очень не отправляют вот такие простыни.
Speaker A
И на простыне вообще, в принципе, э люди обычно пугаются, когда им отправляют большие как бы такие большие объёмные сообщения. А судя по тому, что написано вот здесь в файле базе знания, сообщение довольно объёмное. И как бы каждый раз у
Speaker A
вас получается при каждом диалоге бот считывает вот этот текст, дальше его обрабатывает и на основе него даёт, скорее всего, какой-то большой ответ.
Speaker A
Я бы, соответственно, либо здесь просто бы сократил его вот до какого-то вот такого объёма, вот, чтобы он не больше был выделенного куска. Вот. Потому что в целом, ну, здесь как бы уже есть вот как бы все перечисленные ценности, да? То
Speaker A
есть зачем как бы их дальше ну раскрывать? Они и так, наверное, ну, как бы понятны будут и тому же боту, да, и если мы будем вот это всё раскрытие давать ещё и клиенту вываливать, но кажется, что слишком как бы много, если
Speaker A
честно. То есть я бы тут бы сократил бы вот эту историю, да. Вот это второй вопрос. А надо ли вообще миссию как бы на этом этапе клиенту в принципе как-то давать сразу на втором шаге? Ну, это, конечно, такой вопрос на подумать. он,
Speaker A
ну, как бы каждая компания лучше знает, э, как ей строить как бы диалог, наверное, но как, по крайней мере, я бы здесь как бы на над этим подумал, насколько это действительно нужно. Вот.
Speaker A
Ну и точно также с каждым из файлов, да, то есть чем больше объём внутри файлов, тем дороже будет диалог. Вот. Давайте теперь посмотрим. Я вижу, что у вас подключена ещё АМА CRM. Здесь есть ещё один риск, за счёт которого может быть,
Speaker A
э, а, значит, у нас большой объём. Это когда мы, например, берём информацию из сделки или из контакта. Ну вот здесь у вас вроде этого не происходит. Вот здесь тоже вроде как бы не так много. То есть в принципе приемлемо. Вот здесь вот уже
Speaker A
уже как бы побольше. То есть у вас получается, что вот 1 2 3 4 5 6 7 8 9.
Speaker A
Ну то есть девять полей нужно заполнять как минимум. Тут я бы м ну вот здесь заполняю карточку по мере поступления ответов от него. Вот я бы это убрал бы.
Speaker A
Ну точнее никак не не убрал бы. А важно понимать, что если вы заполняете карточку клиента по мере поступления ответа от него, каждый раз, когда а каждый раз, когда вы мм значит, вот клиент прислал какую-то информацию, которая есть для заполнения карточки,
Speaker A
бот будет каждый раз вызывать вот эту функцию работы сам CRM. И каждый вызов дополнительной функции - это дополнительные токены. Здесь можно было бы оптимизировать таким образом, что собери всю информацию по итогу как бы диалога и в конце диалога уже заполни
Speaker A
карточку. В этом случае он вызовет её только один раз и уже как бы заполнит.
Speaker A
Ну, получается, функция будет вызвана один раз против там, не знаю, пяти-девяти. Вот как у вас это делается?
Speaker A
Да. В этом есть свой минус, что как бы клиент может отваливаться на начальном этапе, может отваливаться на более позднем этапе, но как бы в данном случае э здесь можно ещё решить проблему путём фолоапов. То есть можно, например, сделать отдельный followап, например, по
Speaker A
истечению, ну, не знаю, там, 30 минут или через час после того, как клиент перестал отвечать, вы можете сделать followup, в котором как бы э вызвать, например, ну, написать что-то клиенту, типа актуально для вас или нет, и в этот
Speaker A
момент этим же фолоапом непосредственно сделать заполнение полей. И он заполнит только те поля, которые у него будут доступны на текущий момент. Но в этом случае вы будете точно как бы, аэ, вы будете точно знать м вы будете точно знать, а-э, сейчас,
Speaker A
блин, мысль потерял. То есть в любом случае, да, в этом в этом случае вы будете точно знать, что диалог уже с клиентом не продолжился, он завершён, и теперь можно заполнить как бы карточку. Но это тоже это второй способ как бы оптимизации, потому что на
Speaker A
это точно уходит куча токенов, скорее всего. А, ну вот Александр задаёт вопрос: на чём можно сэкономить при работе чатбота?
Speaker A
Ну вот мы, собственно, 20 минут сейчас об этом [смех] и говорили. Если вы только подключились, то, ну, пересмотрите в записи. А ещё бот не ставит задачу на выбранного менеджера. Возможно, выполнена настройка. Неверно, а не ставит задачу, э, когда клиент заставил номер,
Speaker A
заставить задачу на известного менеджера. Вызови функцию. Ну, тут не совсем AM assign manager. Здесь, скорее всего, во-первых, это не задача, а это смена менеджера, насколько я понимаю. То есть вот эта функция, она отвечает за смену менеджера. То есть в данном
Speaker A
случае, по идее, на шаге 10 он должен, а, э, ну, опять же, да, вот здесь у вас есть отдельная работа с функциями. Я бы вообще вот этот шаг я бы его перенёс бы, вот этот кусок я бы перенёс бы его сюда.
Speaker A
Ну, потому что здесь как бы речь идёт про номер телефона. И здесь речь идёт про номер телефона. И как бы кажется, ну что лучше это в одном месте вот здесь прописать, прямо в одной строке. Вот.
Speaker A
Единственное, что это не задача ответственного менеджера, а можно вообще просто вызови функцию вот это, то есть вот этот кусок, он вообще здесь как бы не нужен получается. То есть можно здесь вот прямо поставить, грубо говоря, и вот просто вот как бы скопировать и вот сюда
Speaker A
вот поставить, а этот шаг его просто закомментируют. То есть вот вот вот так по идее должно работать. Но вот эта функция, повторюсь, она не ставит задачу, она вызывает, она меняет менедже меняет ответственного внутри карточки сделки. А функция, которая отвечает за
Speaker A
задачи - это другая функция. Это функция вот здесь вот, например, встреча. Вот. И она, видите, вот здесь как бы прописана.
Speaker A
Она называется AMD add meet task. Вот. Вот здесь в подсказке она есть. То есть в случае, если вам нужно поставить встречу или там какую-то задачу, ну там у задачи есть два типа. это вот звонок или встреча, то вам нужно прямо
Speaker A
прописать название этой функции, что типа и вызови функцию amo add me task и создай задачу с клиентом. То есть, ну вот вот это использовать. Я сейчас посмотрю, есть оно в инструкции здесь или нет. Функции. Так, каналы АМА CRM.
Speaker A
А-а, блин, а он его здесь не А, ну да, вот оно. То есть вот эти функции, вот их здесь можно прямо вот просто нажать по ним, и они добавятся. То есть как это делается? Вот прямо вот здесь вот сейчас
Speaker A
опять же и, например, ставим, берём функции каналы AMRM и Admit Task. Всё. И пишем и вызови функцию.
Speaker A
Всё. Вот по идее он должен как бы, ну, и менеджер поменять, и задачу ему поставить.
Speaker A
Всё, надеюсь, ответил на ваши вопросы. Значит, давайте теперь двигаемся к следующему. Следующий у нас, э, Виктория, Виктория Флоренс.
Speaker A
Виктория, если вы здесь, дайте, подайте сигнал. Так, я пока а найду вашу чётку, но я почему-то её не вижу.
Speaker A
Ага всё нашёл. Всё, нашёл. Да, Виктория здесь. Отлично. Давайте смотреть, что у вас. Так, мы с вами смотрим, значит, бота, который называется тортик. То есть вот этот бот, да, у него подключен канал. Теперь смотрим, значит, у нас тут есть часть на английском,
Speaker A
часть на русском. Ну, э, странное решение, как минимум. И то, что я вижу здесь - это сразу какой-то очень большой объём промта. То есть вот сразу промт выглядит, ну, как бы очень громозким. Точно мы сейчас найдём, что в
Speaker A
нём исправить. Ну, здесь с ролью вроде всё о'кей, всё понятно. То есть что, где мы отвечаем, да, как нас зовут, кем являемся, чем занимается компания, занимается специализированными под, ну, подарков, да напхуте.
Speaker A
Предлагаем, значит, э разные шарики, цветы и пирожные. Значит, цветы и цели и задачи. Определи, является ли клиент целевым.
Speaker A
А как? Ну вот очень много, если честно, вот очень много целей и задач. Как будто цели и задачи - это должна быть такая типа лаконичная формулировка о том, что твоя цель - это помогать клиентам оформить заказ. Всё. Вот как бы вся цель. Потому
Speaker A
что всё, что вот здесь вот вы описываете, оно должно быть описано либо ниже где-то вот в логике построения диалога, либо в базе знаний, потому что сформируй комплексное предложение, учитывая предпочтение клиента, объясни процесс оформления заказа. Ну вот кажется, что это уже либо, я говорю, это
Speaker A
либо шаги, сценарии, либо, ну, в целях и задачах это слишком много. То есть цель и задачи, они должны быть какие-то, ну, вот типа лаконичные, они должны умещаться вот вот в три в три строчки.
Speaker A
Вот в моём понимании, потому что на самом деле блок цели и задачи он такой он, я бы не сказал, что он сильно ключевой, то есть он больше как для общего понимания, да, вот для общего понимания, какая у него конечная цель,
Speaker A
то есть что он в итоге должен добиться э в, ну, вот в рамках этого клиента. Если мы, например, вот смотрим дальше, да, вот здесь вежливо переводить клиента на оплату, оформление заказа, работать только с новыми клиентами, не дублирую вопросы, если клиент уже ответил. А, ну
Speaker A
вот это даже это больше относится к стиле, к стилистике ответа. Вот сюда в response style, да, отвечай естественно, дружелюбно, с лёгким теплом, уважай контекст. Ну вот вот как бы последние вот эти строчки, они больше вот как бы сюда вот относятся в respстайл, да.
Speaker A
Опять же, понимаете, здесь вот есть какие-то да отвечая естественно дружелюбно с лёгким теплом. И здесь, да, есть friendly, personable and confident.
Speaker A
То есть как бы так как ему отвечать вот так или и или вот так вот. То есть он уже будет как бы что-то выбирать из этого, да, либо какую-то золотую середину находить. То есть надо максимально вот я не знаю, я бы взял,
Speaker A
во-первых, отсюда бы кусок какой-то перенёс бы вот сюда в этот блок, потом выделил этот блок и отправил просто бы его в чат GPT и сказал: "Сократи мне и вот этот как бы промт до там четырёх- пяти строк каких-то очень типа сделай и
Speaker A
сжато лаконично без потери смысла". Всё, он вам этот текст вот как бы, который вы здесь расписываете, он вам сожмёт, ну, более лаконично. Потому что когда вы пишете более так размашитостого Дениста, но это просто будет плохо влиять на ну
Speaker A
на на его ответы. А дальше приветствие. Всегда приветствует клиента в начале только один раз одного дня с учётом времени суток. Использовать приветствие добрый день, добрый вечер, здравствуйте.
Speaker A
Представляться как Анастасия. После приветствия сразу переходите сути вопросы. Узнай имя клиента и обращайся к нему по имени. Ну вот вот это опять же, да, вот оно как бы больше к сценарию относится. То есть приветствие - это просто некие правила приветствия. Вот
Speaker A
как мы его приветствуем, да? Узнай имя клиент, обращайся к нему по имени. Это вроде как уже типа следующий этап. Ну то есть хотя с другой стороны, но если вы в каждом приветствии это делаете, то ладно, о'кей, придираться не буду. Если
Speaker A
сообщение клиент пришло сейчас нерабочее время ну допустим да какая-то инструкция есть. О'кей. Дальше здесь ответ. Здесь это давайте сервер логика построения диалога. Вот я смотрю, она такая вот, знаете, как будто как будто очень большая. И важных уточнений здесь можно. Ну, давайте
Speaker A
смотреть, значит. Приветствие. Поздоровайся представиться. Ну, то есть первое, ну, собери ключевые параметры заказа. А значит, собери ключевые параметры заказа двоеточие. Уточнить дату и время. Ага. Уточнить район, место доставки. Не повторять вопрос, если клиент уже задавал. Опять же, вот
Speaker A
где-то идёт тире, где-то тире нет. Если мы тире видим, то тире как будто относится вообще к приветствию. Вот здесь, типа, да. И при этом странно, что к приветствию у нас относится вот это вот эта часть. Опять же, можно сказать,
Speaker A
что я придираюсь, но просто я же вот смотрю логически, да? Вот если бы я был просто сотрудник, то для меня такая структура, она, ну, как бы не идеальная, да, потому что, во-первых, здесь уже про приветствие было, потом опять здесь про
Speaker A
приветствие мы что-то как бы собираем. Опять же, если мы первое, шаг один - это там например приветствие поздоровайся и представься. Потом второе, собери, шаг два, собери ключевые параметры заказа. В двоеточие идут параметры заказа. Вот это не повторяй вопрос, если клиент их уже
Speaker A
указал. А-а, да, это можно здесь, э, как бы о'кей. Ну вот, да, здесь можно не повторяя вопрос, если клиент уже указал ранее. То есть или тут собери ключевые параметры заказа, но я бы прямо вот здесь бы в скобочках это бы и прописал.
Speaker A
если клиент не указал это ранее, то есть просто вот так, не отдельным как бы вот этим блоком. Если клиент спрашивает про доставку, уточни район, вышли данные из базы знаний по районам.
Speaker A
Question answers delivery table. А значит, ну здесь какая-то таблица, да, используется. Вышли данные из базы знаний, уточни район. Ну давайте сначала в базу знаний посмотрим, что в базе знаний.
Speaker A
Аа что в базе знаний? Ну, в базе знаний есть, а, ну, вот стоимость доставки, наверное, да? То есть вот есть Cost of Delivery. Ну, кстати, вот здесь тоже вот стоимость доставки, да, вот она разбита тут по разным как бы файлам. Давайте их
Speaker A
посмотрим. Ну да, они разные, собственно, и в принципе информации как бы, наверное, неплохо, что они разбиты.
Speaker A
Вот таким образом. Единственное, что тут можно было бы, это я бы все названия доставки я бы привёл к единому виду.
Speaker A
Видите, здесь написано cost of там лагуна delivery, а здесь delivery cost bankwn. Напишите лучше тогда cost of cost of bank delivery. Ну, мне кажется, так будет как бы лучше опять же для бота, потому что у него чёткая структура, понятно, где что. И и вот эту
Speaker A
структуру, её можно использовать, кстати, в в инструкции. То есть, если мы, например, вот здесь смотрим ну вот как, где у нас тут вот, аэ, вышли данные из базы знаний. Ну, вообще такое понятие, как база знаний, у него нету этого понятия, да? Это для нас есть
Speaker A
понятие базы знаний. Для него это функция, функция, которая называется getфатек. Поэтому здесь можно было бы как сделать, что если клиент спрашивает про доставку, уточни район и вышли данные, используя функцию get fileте.
Speaker A
Ну, например, давайте я вот сейчас сделаю просто пример вам, чтобы было понятно, и потом, значит, ну, закомментирую. Значит, уточни район и вышли данные.
Speaker A
Значит используя функцию getкст. Значит, теперь вот так вот делаем. Пам-пам. Cost of [смех] вот так вот делаем. Ну, это такой пример такой как бы может быть сложный может показаться. Например, место, значит место Давайте так, район плюс район. Значит,
Speaker A
то есть, по идее, для бота вот это понятно, да, что у меня здесь есть какое-то название файла, которое начинается на cost и прибавляется к нему ещё конкретный район уже тот, который клиент как бы указал.
Speaker A
Значит, и здесь, значит, по районам, значит, по районам и вышли данные из ПРЗ. По районам. Ну вот опять же, если мы говорим про таблицу, давайте смотреть, что в таблице.
Speaker A
Значит, таблиц тут довольно много. Блин, какие у нас продвинутые пользователи уже стали. Такие таблицы добавляют. А, ага, поспешил с выводами. Так, а question, answer delivery 2 table. Какая минимальная? Ну, вообще, честно говоря, я не знаю, зачем здесь вы используете
Speaker A
таблицу, потому что таблицы, как правило, они всё-таки используются, а тем более, что у вас здесь нету как будто мм ну вот если бы у вас был вот здесь ещё район, отбор по району, ну тогда можно было бы как-то сопоставить,
Speaker A
но визуально кажется, что таблица сейчас свою функцию просто не выполняет, потому что, во-первых, у неё нету описания, то есть как бы question answers delivery 2 table, А, ну какую ему вот я не знаю, Delivery table просто есть? А, ну нету
Speaker A
просто, да, Delivery. Ну хорошо, в названии вроде как есть какая-то информация, да, о доставке, но непонятно почему. А почему она дублируется с базой знаний? Ну то есть как бы по идее база знаний должна эту функцию выполнять. То есть вот это всё в базу знаний лучше
Speaker A
запихивать. Таблица нужна для тех случаев, когда у вас есть какой-то прайс-лист и он довольно большой. То есть, когда у вас прайс-лист содержит, не знаю, там, например, 100 плюс строк, и вам нужно по каким-то параметрам в этом прайс-листе что-то находить, вот
Speaker A
тогда это можно использовать, да, какие-то количественные там показатели. Для рубрики Вопрос-ответ лучше всё-таки использовать базу знаний, ну, либо на крайний случай большие файлы. Хотя, ну, как бы вот потому что я вижу, всё-таки лучше использовать прямые вопросы. Давайте другие таблицы
Speaker A
посмотрим. Аэ, опять же вопрос-ответ, оплата, это всё лучше в базу знаний, то есть как бы как будто разбивать это на разные таблицы. Ну, а смысл проще? Вы могли тогда просто создать одну таблицу и при каждом вопросе просто направлять бота в
Speaker A
эту таблицу, чтобы он там находил вопрос. Ну и, кстати, в таком контексте он её тоже находить не будет, потому что он её найдёт только в том случае, если почему вот здесь в данном случае не надо использовать таблицу, потому что,
Speaker A
понимаете а чтобы бот нашёл эту строчку, клиент должен прямо вот слово в слово задать вопрос вот именно таким образом. И тогда он найдёт вот эту информацию, вот эту строчку. Во всех остальных случаях он её просто тупо не найдёт. У нас есть другой
Speaker A
режим работы с таблицами через действия. А так, сейчас я посмотрю, может быть, у вас таблица здесь. Подключим вызов менеджера. Привление сети кос пишет претензию. Готов к оплате уточнения равен. Ну вроде да, вроде вроде этого здесь нет, но у нас есть отдельный режим
Speaker A
по работе с таблицами, который позволяет как бы использовать определённый запрос такой типа поиск векторный поиск. ну, такое что-то подобие больших файлов, но только по таблице. А, но обычно мы это используем для маркетплейсов, например, когда у них большое количество вопросов
Speaker A
и ответов в разрезе артикулов, то мы вот здесь можем прописать такие специальные запросы там или цепочки запросов, которые вот позволяют там, ну, как бы сделать запрос с учётом векторного поиска к таблице. Но это я такой сказал бы для продвинутых пользователей. Я сам,
Speaker A
честно говоря, сейчас с ходу даже не вспомню, как этот запрос здесь должен писаться. Надо будет это, а, здесь как-то сделать более интуитивно понятно и, может быть, сразу готовый запрос пропихивать при выборе таблицы. Вот. Но, э, в вашем случае как будто это не надо,
Speaker A
потому что тот объём вопросов, который у вас есть, вам нужно просто взять и вот из вот этих таблиц перенести в базу знаний. Ну да, база знаний, она чуть станет больше, она как бы, ну, кратно, да, может быть, в два раза станет
Speaker A
больше, но пускай как бы зато это будет работать. Сейчас просто у вас эти таблицы, скорее всего, не работают.
Speaker A
Сейчас, да, я много говорил, сейчас посмотрю. А, мм, сейчас посмотрю. Есть про доставки по районам, есть поддержка рекомендовала сделать таблицу.
Speaker A
А, интересная рекомендация. Может быть, они думали что-то. Ну, надо понять, почему они так рекомендовали, да? То есть, что это за проблема была. А тоже вот тут Дамир К8 задаёт вопрос. Мы будем смотреть, как в реальности отрабатывают эти промты.
Speaker A
скорее не будем, потому что в этом нет никакого смысла. Это очень просто растянется. Нам не хватит часа. Мы сейчас как бы выясняем концептуальные такие, я бы сказал, вещи, которые, ну, они 100% влияют как бы на качество. То есть вот они концептуальные и они точно
Speaker A
сделаны, например, неправильно. Ну, то есть в данном случае вот я, честно говоря, не знаю, что вот он здесь вообще вызывает в этой таблице. То есть вот вызвал он эту таблицу и и что дальше он с ней делает. То есть он там не может,
Speaker A
ну, он там ничего не находит, скорее всего. При этом ещё и токены сжирает на это. Поэтому, ну, я не знаю, я бы всё-таки пере перенёс это всё в Ну давайте посмотрим сейчас, что ещё есть.
Speaker A
Ну да, ну за зачем? Ну, то есть всё, что там, где есть прямой вопрос и прямой ответ, это всё должно идти в прямые вопросы. Таблицы для этого, как правило, не используются. Мы можем использовать, вот я, как я сказал, вот этот
Speaker A
дополнительный режим работы с таблицами, где путём векторного поиска находить вот эти вопросы. Но это опять же это нужно, наверное, в каких-то исключительных случаях, когда вопросов не ну там не не ну там не до 100 штук, а когда их там
Speaker A
200, 300, 500, там 1.000 вопросов. Вот тогда имеет смысл использовать таблицы и там векторный поиск по ним. В вашем случае как будто этого не требуется. Ну, я сильно сомневаюсь, что вот тут по каждой таблице по 100 вопросов. То есть
Speaker A
там, скорее всего, ну, там по по 20, может быть, максимум в каждой таблиц. А, ну вот каталог, каталог ещё куда не шло, в принципе, да. То есть, если мы, например, говорим, что бот ищет, а, ну, как бы вот конкретно по названию, да,
Speaker A
или там по, не знаю, по какому-то, э, цветку, по составу букета, то, да, вот здесь это будет работать. Единственное, что здесь мне не нравится в ваших таблицах, это вот вот это вот описание таблицы. Видите, чтобы бот понял, для
Speaker A
чего она используется. То есть у нас есть с вами каталог Flowers Table. Ну, вроде как бы здесь из названия написано, но я бы всё равно бы сюда ещё дополнительно прописывал. Плюс здесь иногда можно прописывать какие-то правила поиска, то есть брать первые
Speaker A
там, не знаю, пять пять вариантов, да, через оператор Limit. Это можно здесь указывать, и он будет этому следовать.
Speaker A
А давайте дальше. Давайте дальше. А сценарий для торта. А опять же вот ээ не совсем понятно, как мы как мы перешли от шага один, да? И вот здесь какими-то там вопросами, которые мы задаём, сразу к сценарию для торта. Сценарий для торта: тип бента,
Speaker A
классический, количество персон, аллергия. То есть зачем это здесь? Что нам с этим делать? То есть как бы вообще непонятно. То есть вот вот этот как бы блок, его точно надо как-то куда-то убирать. Его либо надо убирать в базу
Speaker A
знаний отдельно, просто как отдельный какой-то файл, который так и называет там сценарий для торта, либо, ну не знаю, либо какое-то пояснение давать, а что это за этап? То есть что мы на этом этапе делаем? То есть вот я всегда, знаете, как бы легко
Speaker A
анализировать промт. Вот я о вашей теме ничего не знаю о вашей о вашем бизнесе, да? И получается, что как бы вот я не знаю и бот не знает тоже. То есть вот если я не понимаю, да, то и бот тоже не
Speaker A
поймёт, что с этим делать. То есть ну какая-то идёт структура, но только непонятно, что это за структура, почему она здесь, как её использовать. То есть здесь нужен чёткий, чётко должно быть прописано, что с этим делать по итогу вот. А если клиент спрашивает про
Speaker A
наличие сегодня или завтра, после семнадцати или до 19:00, опять же, вот это можно унести в базу знаний. То есть как бы, ну вот можно можно можно вот это всё вынести в базу знаний и вообще вот это здесь не прописывать. Ну не знаю, может
Speaker A
быть, это у вас как-то нестабильно работает, но я бы сначала бы попробовал без этого в промте. То есть типа зачем это прописывать, если можно прописать эти ключевые слова? А типа клиент клиента интересует наличие на сегодня или завтра после 17:00 и до 19:00.
Speaker A
Всё, как бы дальше. А, ну, единственное, что у вас здесь есть отдельный файл ещё call the manager. Ну, можно файл просто переназвать, сделать отдельный файл call the manager и сделать отдельный файл вот чисто вот с этим названием, грубо
Speaker A
говоря, и вообще убрать вот вот это отсюда, это просто будет всё равно дешевле, потому что вот этот блок, он явно больше, чем, ну, чем если это в файле файл просто запихнуть. И опять же за счёт уменьшения промталу работать.
Speaker A
Если клиент спрашивает про наличие сегодня или завтра, утро после 22 наш цех уже не работает. Можем оформить заказ на завтра. Но опять же, если это так значимо, то я бы вообще это в отдельный блок бы, э, ну, как бы
Speaker A
выделил. И опять же вот как бы здесь сценарий для торта, это это только к торту относится или это относится ко всем как бы ко всем э вот этим сценариям, если это относится только для торта.
Speaker A
Ну, тут, кстати, вообще такая мысль у меня сейчас возникла тоже, что не исключено, что вам вообще вот эти разные сценарии нужно вообще делать на разных ботах. То есть, если, ну, видно, что вот здесь у каждого сценария есть какой-то
Speaker A
свой объём, да, своя база знаний, свои какие-то моменты, аа если, например, таких у вас там сценарий два-три, то вам имеет смысл сделать двух-трёх разных изолированных ботов и под каждый свой сценарий. Я сейчас не говорю, что это прямо вот ваш случай. Просто для тех,
Speaker A
кто нас смотрит, может быть, им будет полезно, что мы можем сделать трёх разных ботов под каждого под свой сценарий. Сделать четвёртого бота администратора. Бот-администратор задаёт наводящие вопросы, то есть квалифицирует клиента, да, уточняет, какую услугу, какой он хочет сделать заказ, и дальше,
Speaker A
аэ, собственно, переключает его на нужного бота. Переключение в этом случае оно делается через через действие. Здесь есть вот такая штука, которая называется переключение действующего бота. Мы здесь можем выбрать бота, на которого нам нужно переключить, например. И в зависимости от конкретного случая мы
Speaker A
просто в инструкциях основного бота прописываем, что если клиенту надо там цветы, тогда переведи его на этого. Если клиенту нужны там пирожные, переведи его сюда. Ну тот другой, да, может возникнуть вопрос, что делать, если клиенту нужно и то, и другое. Ну вот тут
Speaker A
нужно думать, как здесь в принципе можно объединить. Потом он с одним пообщается с ботом, потом он со вторым как бы пообщается и потом объединит это всё на уровне бота администратора в один заказ.
Speaker A
То есть такое тоже можно. Это, конечно, схема такая посложнее в целом она требует, ну, трудоёмкости настройки, но она возможна. И тут уже надо смотреть, ну, насколько как бы отрабатывает. Если хорошо отрабатывает в рамках одного промта всё, ну, о'кей. Если где-то
Speaker A
видите, что начинает путаться, берёт а одну информацию из другого сценария, то, ну, во-первых, здесь надо перестраивать сампромт. Вот видно, что здесь много всего чего-то как бы очень очень перегружено, как бы, и какие-то, знаете, вот структура странная. То есть, я
Speaker A
говорю, вот идёт шаг один, потом сценарий для торта, потом опять какой-то комментарий, потом сценарий воздушные шары. Опять же, если клиент интересуется воздушными шарами, уточни, для кого выбирают: детские, муж или женские.
Speaker A
Отправь прайс вызвать функцию gete текст. А, ну, допустим, хорошо, уточнить тип, там тт, отправить несколько вариантов коллаже из базы знаний. Ну вот это не сработает точно. То есть и предложить ознакомиться с большим количеством на сайте. То есть, если вы
Speaker A
хотите, чтобы он отправил конкретные коллажи из базы знаний, вы должны указать прямо конкретную функцию, что отправив несколько вариантов коллажей, вызвав функцию getфатек, указать конкретный файл, который вам нужно, ну, в котором эти коллажи содержатся. Вот для коробки сюрприз размером.
Speaker A
Ну вот опять же непонятно для коробки сюрприз. А у нас пока речи не было о коробке, вроде. Ну почему мы сразу тут о коробке что-то говорим? То есть, понимаете, вам как специалисту в своей области это кажется понятным, очевидным.
Speaker A
Ну, кстати, вот здесь точек везде не хватает. Это тоже не очень хорошо. То есть лучше их проставлять, чтобы, ну, было понятно, где зака начинается предложение, где оно заканчивается, потому что, ну, как бы видите, здесь хоть и с новой строки, но для него это
Speaker A
может быть, ну, хуже как бы звучать. Вот отправить в каталог, вызвав функцию такую-то. После подтверждения заказате на срочно бизнес баланс. Ну, допустим, да, но всё равно вот как-то вот структура какая-то очень такая вот она, знаете, такая вот немножко непонятная
Speaker A
для неспециалиста в вашей сфере. Я бы как-то постарался бы всё-таки более более структурированно более понятно это описать. Это точно даст при этом не размашисто, то есть в том же объёме, но просто более понятно шаг 1 2 3, потому что у нас всё ещё идёт шаг
Speaker A
один, да, если вы заметили, как бы приветствие. И при этом у нас какие-то сценарии мы тут описываем, да, потом уже шаг два, подготовка к оплате. Ну нет, явно тут как бы либо вот эти сценарии, их надо как-то отдельно выносить и здесь
Speaker A
просто давать на них отсылку. Ну как-то иначе мне не нравится, что они в шаге один находятся. Вот.
Speaker A
Дальше подготовка к оплате. А, ну я понял, да, почему здесь, то есть типа здесь могут быть разные сценарии, поэтому здесь типа на первом шаге мы это выясняем в зависимости от сценария. Ну, я бы это вынес бы вообще в отдельный
Speaker A
блок, который бы назвал прямо сценарий воздушные шары, сценарий там, а, там тт, сценарий Т-ТТ, то есть разбил бы их на три разных сценария, а здесь в приветствии просто определил бы на шаге один, что далее следуй по сценарию, обозначенному в таком-то блоке. Вот.
Speaker A
Подготовка к оплате. Если клиент готов заказ подтвердить, считать итогую сумму, пообещать прислать реквизиты, вызвать функцию, отправить реквизиты. А работа с возражениями.
Speaker A
Ну опять же, да, если мы работаем с возражениями, давайте там выделим это вот, например, в отдельный блок. То есть вот у нас работа с возражениями. Так, ну единственное, что вот это вот не надо было так вот что отменить не даст.
Speaker A
Ну ладно, трагедия. А значит, на возражение дорого объяснить ценность. Накет хлеб стоит 185 бат.
Speaker A
Садики, школа, да. Ну налоги и бизнес виз не бесплатно для нас. 2.000 Вт 2.000 руб. просто купить. Ну работа с сомнениями. М, ну опять же, да, вот здесь вот можно как бы выделить это просто в отдельный блок.
Speaker A
Работа с возражениями, работа с сомнениями. Хуже от этого не будет, как бы в целом работа с функциями. Если клиент по повторный передать, Если клиент повторный, передать менеджеру, вызвав функцию. А, ну, допустим, о'кей, для проверки срочного заказа вызвать функцию тт.
Speaker A
А, ну вот тут, наверное, и, да, то есть тут как-то странно, одна функция, вторая, то есть как минимум типа вызвав функции и да вот я не знаю, я очень вредный вот в этих моментах. Мне кажется, надо очень как бы чётко писать
Speaker A
вот правильно, а, чисто вот синтактически и фанечески, то есть правильно ээ как бы писать вот эти вещи, в конце ставить точку, чтобы не было вот таких вот как бы разорванных. Оно, знаете, вот как бы оно там 0,1 какой-то
Speaker A
процентик даёт, но и то хорошо, то есть и то уже как бы меньше будет этих моментов. Так, ну, ограничение, ладно, здесь уже срочные заказы. Если заказ на сегодня, ну опять же, да, вот срочные заказы, вообще не очевидно, что это
Speaker A
заголовок. Естьли заказ на сегодня или завтра, объяснить особенности. А, работаем по при наличия заголовок. Мм, ну я бы опять же никогда не говори, что ты бот. Ээ это лучше в блог запрещено говорить. То есть запрещено, что ты бот.
Speaker A
То есть как бы, ну, то есть это туда правил доставки указывают тарифы по районам и времени суток. Не очень понятно вот это стандартная время, утренние, ночные доплаты.
Speaker A
Ну, тоже как-то вот всё в кучу, если честно, как будто бы. А не хочу, чтобы вы подумали, что я сильно придираюсь, но аа формулировка стандартное время, правила оплаты. Ну, то есть вроде да, вроде что-то есть действительно как важное уточнение, но что-то точно можно
Speaker A
распределить на какие-то другие места, на там, не знаю, на на базу знаний, на ещё что-то. То есть вот там какие-то какие-то вещи, может быть, доставку. Вот у вас по доставке, я в базе знаний тоже смотрю, много довольно вот таких вот
Speaker A
файлов, да, вот этих по каждой доставке. Я бы для доставки вообще бы сделал отдельного бота. У нас был такой кейс, где мы делали тоже нахукете байки.
Speaker A
Ну, то есть аренда байков. И там был отдельный бот, подчинённый для именно для доставки, потому что доставка нахуйте имеет там свои особенности, кучу кучи вариаций. И я бы сделал просто отдельного бота, которого мы бы вызывали именно в тот момент, когда человек там
Speaker A
интересует о доставке или когда это уже действительно нужно. Потому что сейчас получается, что там до доставки там до района могут не дойти. При этом каждый раз при любом ответе вызывается этот большой объём базы знаний по доставке.
Speaker A
Ну, кажется, что здесь можно это сптимизировать. Ну, ещё момент, что на русском языке, да, то есть как будто, если вы работаете над хуке, то, ну, много чего на английском, да, в целом, как будто имеет смысл весь промт тоже перефигачить на английский. Это
Speaker A
тоже будет дешевле, потому что я уверен, что вот с учётом всего того, что я вижу, у вас стоимость такая не маленькая получается диалога, она точно выходит за рамки стандартной стоимости. И, ну, здесь точно можно это оптимизировать.
Speaker A
А, надеюсь, Виктория немножко помог вам. Вот поэтому, э, давайте я сейчас посмотрю вопросы, которые были по ходу моего разбора. Вот.
Speaker A
И дальше перейдём к следующему. Аа, так. Антон, пользуясь случаев, хочу уточнить ещё один вопрос по другому клиенту. Столкнулись с проблемой передачи данных, которые бот должен сохранять в стороннюю базу данных постг через вебху. Сам вебху настраили по инструкции поддержки, но так и не
Speaker A
добились передачи данных. Можете посмотреть или подсказать. Но сейчас нет, не смогу. Как бы здесь нужно разбираться с поддержкой. Можете прислать мне в личку, а просто номер заявки. Мы попробуем разобраться. Ну, вообще, по идее здесь надо предметно смотреть. Ну, вебхуки отправляются, то
Speaker A
есть надо смотреть дальше в логах. У нас вот здесь вот есть, если у вас есть права администратора, у нас есть вот такая штука логи запросов. В логах запросов здесь можно посмотреть все логи, которые были, ну, по конкретным запросам. Вот. И дальше можно
Speaker A
посмотреть, а что Webhook возвращает, какую ошибку, какой какие детали. То есть тут есть там свои, ну, как бы детали внутри. То есть это позволяет анализировать отправку вебхуков.
Speaker A
Посмотрите, какие он там вам коды возвращает какой ну там какие ошибки, и исходя из этого уже там сможете разобраться. Иногда заказывают только торт, а иногда комбо, торт, шарики и цветы. Ну, тут надо смотреть, как я и сказал, да, как отрабатывает. То
Speaker A
есть, если всё-таки чаще изолированно заказывают, я бы делал разных ботов. если заказывают. Причём даже вот, кстати интересно что например если вы сделаете трёх разных ботов, а четвёртого бота у вас будет бот администратор, а пятого бота вы, например, сделаете по доставке, то чисто
Speaker A
по доставке можно сделать вообще одного бота, которого будут вызывать все вот эти три бота и, но который будет чисто за доставку отвечать. То есть, если есть где-то возможность изолировать какие-то куски, большие куски, которые там, ну, такие объёмные, то лучше их изолировать,
Speaker A
потому что в этом случае вы будете и на стоимости экономить, и качество от этого, скорее всего, повысится. Как лучше реализовать идею, что исходя из первого сообщения клиента вопрос про доставку или про комплектующий или про оплату, нужно действовать по разным
Speaker A
сценариям. Поддержка тот же рекомендовала занести в таблицу первые сообщения и соответствующие шаги, на которые нужно переходить. А в общей логике уже все шаги прописать. А-а, ну я не знаю, кто у нас там в поддержке рекомендует в таблицу это всё заводить.
Speaker A
Сейчас встречу закончим, сделаем разбор полётов, шапки какие-то полетят, наверное, чьи-то. Вот. Ну, вообще, как бы, а опять же, если это разные такие типа сценарии, эти сценарии можно описать в самом промте. Ну, вообще, в принципе, да, если мы говорим про
Speaker A
сценарии, то сценарий, он прописывается в основном промте. Шаг один, шаг 2, шаг 3, шагчетыре, шаг 5, шагшесть. Если, например, вы понимаете, что эти сценарии могут быть довольно объёмными, ну, вот, как я и сказал, сделайте вообще отдельных ботов под каждый сценарий.
Speaker A
Сделайте бот администратора, который задаёт первый вопрос, типа, что нужно клиенту, да? А дальше переводите его на бота, который уже вот отвечает чисто за этот кусок. Ну, в вашем случае тут вопрос про доставку, про комплектующий про оплату, он вроде как в рамках одной
Speaker A
предметной области. Кажется, что отдельных ботов делать тут, наверное, будет не совсем правильно, потому что всё-таки это одно и то же. Просто типа шаги будут разные. Ну о пишите эти три варианта сценария в самом промте. Прямо пишите типа сценарий один, сценарий два,
Speaker A
сценарий три. И дальше пропишите вначале типа: "Если клиент спросил это, действуй по сценарию один. Если клиент спросил это, действуй по сценарию два". Вот.
Speaker A
Либо всё-таки сделайте отдельных ботов. Пускай у этих ботов будет одинаковая база знаний у всех трёх, например.
Speaker A
Аа её можно будет просто продублировать. То есть когда вы одного бота сделаете, потом его можно просто откопировать и всё, у него база знаний перенесётся. И при этом бота администратора, который задаёт этот вопрос, после того, как клиент ответил, вы переключаете уже на
Speaker A
какого-то конкретного бота, и он уже идёт по нужному вам сценарию, и там не будет у него других сценариев.
Speaker A
Соответственно, они его не будут сбивать. Ну и как бы всё, всё должно работать. Здесь надо, знаете, пробовать.
Speaker A
Вот здесь с опытом это приходит. Здесь как бы сложно ну определить это до начала, пока ты не начал делать. То есть потому что всё-таки, когда начинаешь делать, ты уже понимаешь, ошибается он, не ошибается.
Speaker A
Если начинает ошибаться, тебе приходится как-то там что-то выдумывать, изолировать вот эти куски. Поэтому это зависит от этого. А можете тезисно обозначить, как максимально удешевить конкретно этот промт в токенах. То есть указать ключевые узлы, влияющие на цену.
Speaker A
Ну, я уже про это сказал. Первое- перевести промт на английский язык. Второе- уменьшить, э, внутри файлов базы знаний сам объём текста. Возможно, разбить этот текст на, ну, на другие файлы базы знаний. Разбивка этого текста на другие файлы базы знаний, она увеличит
Speaker A
стоимость, но в совокупности это может дать всё равно сокращение, потому что он будет вызывать более короткие файлики с более меньшим объёмом текста. и только в тот нужный момент, в который это нужно, и это позволит, ну, сократить как бы
Speaker A
стоимость. Почему вы не используете модель оплаты с абонентской платой, заботы и каналы, но токены при этом оплачиваются практически по себестоимости?
Speaker A
Ну, потому что мы придумали вот такую схему оплаты. Мы решили такой способ монетизации использовать. Нам он больше нравится. Ну, и, судя по росту наша клиентская база, клиентам тоже как бы этот вопрос нравится.
Speaker A
Нет у меня доступа к логам. Напишу в личний. Благодарю. Хорошо, Роман. Давайте. У нас у нас последний кейс. Это кейс от Сергея и его А и его ботпродавец Secret.
Speaker A
Так сейчас секунду. Сергей. Да, Виктория. Вы можете дать обратную связь, помог вам? А помогли ли вам мои комментарии или нет? А хочется, чтобы они вам помогли.
Speaker A
Так, а мы давайте посмотрим а бота, бот продавец Secret. Значит, и Сергей, если вы здесь, то, пожалуйста, тоже дайте о себе знать. Да, Сергей Шаталов, я вижу вас. Ну, Сергей, пока я начинаю разбирать ваш, а, ваш промт, то вы пока
Speaker A
напишите ваши вопросы, которые у вас есть. То есть какие есть проблемы с этим промтом, есть ли они вообще? Давайте смотреть сам пром. Ну, видно, да, что промт тоже тут, э, создавался как будто через э через наш вот этот конструктор
Speaker A
промтов. Это неплохо, потому что у него, по крайней мере, сразу есть чёткая структура, да, и чисто визуально это гораздо удобнее смотреть. Ты профессиональный менеджер по продажам онлайн. магазин За дверью. У тебя нет имени. Ты эксперт в области продаж,
Speaker A
владеющий различными фреймворками, техниками продаж. Онлайнмагазин за дверью специализируется на продаже скрытых дверей. Компания стремится предоставить клиентам высококачественные продукты и решения, которые удовлетворяют их потребности.
Speaker A
Цели и задачи: объективно проводить, эффективно проводить продажи, выявлять потребности клиентов, предлагать оптимальные решения, квалифицировать лиды, работать с возражениями, доводить до сделки, до закрытия, обеспечивая высокий уровень выд клиентов.
Speaker A
Ну, очень много общих фраз, на самом деле. Вроде как бы даже если бы мы вот есть ощущение, что если бы мы вообще этот блок убрали здесь, ничего бы не поменялось. То есть хочется, чтобы в этом блоке всё-таки что-то была какая-то
Speaker A
конкретика, да, что наша задача типа задать клиенту наводящие вопросы, взять у него номер телефона и договориться на замер, например. Вот это как бы некая цель понятная, да, измеримая, что достигли мы этой цели или не достигли.
Speaker A
Так, это в целом, в общем, вот эти то, что описано, оно вот даже исходя из вот этого уже как бы подразумевается. То есть для боту ему напишите вот это, не напишите, для него ничего не изменится.
Speaker A
А, как я уже говорил ранее, чем меньше прот, тем лучше. Поэтому вот этот блок либо надо переписать, либо можно смело его убирать. Всегда здоровайся с клиентом в начале разговора, не называй компанию, которая которую представляешь.
Speaker A
Ну, странно, но о'кей, допустим, не надо называть. Хотя обычно наоборот называют. А значит, пиши от мужского лица. Общайся в уверенном, профессиональном стиле с элементами разговорной речи. А демонстрирую экспертность и живую увольчённость разговор. Ээ использую позитивный язык и проактивный подход. Ну
Speaker A
что такое позитивный язык и проактивный подход? Не очень понятно. Демонстрирую экспертность. Ну о'кей, он может какие-то фразы добавлять, возможно, экспертные. живую вовлечённость в разговор. Ну, не очень понятно, что значит живая вовлечённость в разговор.
Speaker A
Как её измерить, живая она сейчас или неживая? Представляю перечисленную информацию в виде списка. Ну, здесь есть конкретика, да? Используй профессиональные слова, создающие положительный образ продукта. Ну, я бы здесь добавил только, наверное, профессиональные слова из области чего, да? То есть какие профессиональные
Speaker A
слова? То есть, ну, здесь важно понимать, что есть профессиональные слова, что нет. Если мы подразумеваем какие-то профессиональные слова из конкретной области, лучше здесь их указывать. Избегай сомнительных формулировок. Возможно, обычно, примерно, наверное, может быть. Ну, тот, опять же, тут вопрос: а он использовал?
Speaker A
То есть это как бы обычно, ну, просто чат GPT он не использует такие как бы вещи. Поэтому тут надо понять, вы её добавили из нужды и потому что он это говорил или просто потому что вам так показалось. Если вам так показалось, я
Speaker A
бы убрал. Не перечисляю, не повторяй информацию, предоставлено перед номеране. Не подводи итоги. Ну, о'кей, да? То есть здесь есть конкретика, опять же, да? Не перечисляй, не повторяйся и не подводи итоги. Дальше идут, а, идут, э, шаги. В первом сообщении,
Speaker A
независимости от того, что пишет клиент, поздоровайся и ответь на вопросы по порядку в одном сообщении. Здоровайсь только один раз за весь диалог и задай клиенту вопросы шаг за шагом, если с контекста написания ранее не понятно.
Speaker A
Всё о'кей, вопросов нет. Единственное, точки нет. Значит, спроси город клиента, объяснив, что это необходимо для точного расчёта стоимости района. Не уточняй.
Speaker A
Спроси, какая кромка по периметру полотна интересует. Кромка ABC. Хромированная, алюминиевая. Здесь всё как бы довольно конкретно. Вопросов пока нет. Попроси указать размеры проёмов или полотен и уточни, сколько дверей. А, ну, кстати, да, вот мне нравится, что здесь у Сергея вот есть вот такие уточнения в
Speaker A
скобочках, да, они как бы сразу по ходу идут, то есть вот раз и сразу уточнили, да, раз написали, сразу уточнили. Я тоже люблю такой стиль. Мне кажется, что это неплохо как бы работает и понятнее просто вот оно не перегружает как бы
Speaker A
промт. Сколько дверей на открыванием с открыванием на себя или от себя? Смотрим со стороны, где дверь в одной плоскости со стеной. Если ранее неизвестны из контекста диалога, объясни, что от количества дверей зависит размер скидки.
Speaker A
Не задавай вопрос про открывание, если дверь раздвижная. А уточни, что именно прислал клиент, размеры проёма или полотна. Внимательно выслушай клиента и задай уточняющие вопросы по методике спин. Выясни текущую ситуацию, проблемы и последствия их потребности. После сбора всей информации напиши: "Я передаю
Speaker A
информацию меджатся с вами. Вызови getтек". Ну, всё чётко здесь написано. Если у вас есть другие вопросы, напишите мне. А-э, так. Ну, а это Ага.
Speaker A
Ну да, здесь, а я бы вообще вот, честно говоря, вот этот бы кусок я бы вынес его в базу знаний.
Speaker A
То есть кажется, что а зачем а вот это здесь писать, да? То есть я бы просто бы сделал файл базы знаний, вот этот условный какой-то, да, файл, а и он свяжется с вами. А, ну здесь возможно типа рабочие часы менеджера.
Speaker A
Ну если это работает вот с такой как бы конфигурацией, то о'кей, принимается. Если с этим есть какие-то проблемы, то надо подумать, как здесь вот это пере пере, видите, потому что опять же вот видите, я споткнулся, то есть для меня
Speaker A
не сразу стало понятно, что имеется в виду. То есть я такой раз как бы сначала подумал одно, а потом такой: "А здесь, наверное, кусок про часы", да? И вот у бота, у него точно так же он может где-то он может в какой-то ситуации он
Speaker A
может это понять в явном виде, а в какой-то ситуации он может это просто затупить и не понять, что вот надо собрать такой вот ответ и и взять кусочек из файла базы знаний. Поэтому, если можно это как-то пере переделать,
Speaker A
лучше это переделать. Если клиент спрашивает, что входит в стоимость двери, вызови функцию тт. Ну, опять же, здесь в целом это можно и не писать, если просто прописать это в базе знаний.
Speaker A
То есть у вас, в принципе, вот здесь это прописано. По идее, он и без этого должен этот файл вызывать. То есть вызывать каждый раз, прописывать по каждой ситуации конкретный файл базы знаний не нужно. Для этого есть база знания, что там есть заголовок как раз у
Speaker A
файла, по которому он определяет, нужно этот файл вызывать или нет. Поэтому можно, ну, спокойно этот файл оставлять, а эту строчку просто убирать. Если нужно определить рабочее время менеджера, когда он сможет ответить: "Вызови функцию working hours of managers". Но опять же
Speaker A
м ну мы пока одну только ситуацию, да, с этим увидели и вот здесь уже прописали, типа, зачем здесь это нужно ещё? Если клиент спросит рабочие часы менеджера, то этот файл и так будет вызван без вот этого. Если клиент написал, что двери
Speaker A
нужны несрочно, а на будущее, просто присматривается, вызове функцию. Но опять же тогда и не надо здесь это прописывать. Он здесь внутри файла всё прописано, оно и так отработает. Вот. Ну то есть вот этот блок он как будто здесь
Speaker A
такой излишний. Если вы его добавили опять же из нужды, потому что бот где-то там в каких-то ситуациях это не вызывал, о'кей, оставляйте. Но фундаментально кажется, что он ни на что не влияет и его можно убрать. Запрещено использовать нецензурную лексику. Запрещено давить на
Speaker A
клиента быть наящим агрессивным в продажах. Запрещено обедать, обещать то, чего мы не можем не предоставляем.
Speaker A
Запрещено отвечать вопросам на вопрос. Запрещено отвечать одинаково. Называть имена, путать товары, ттт, давать скидки бесплатные. Ну о'кей. Если опять же вы здесь добавили это, исходя из каких-то конкретных ситуаций, о'кей, но есть ощущение, что здесь как будто много чего-то.
Speaker A
Чего вот как бы не использует. Итак, ну, например, он явно вот сам по себе не давит на клиента. Ну, тут надо ещё постараться. Есть некоторые кейсы такие компании, которые наоборот хотят, чтобы он давил. И вот там надо постараться ещё
Speaker A
его убедить в промте так, чтобы он был навязчивым и давил. Поэтому даже если эту строчку уберёте, кажется, что, ну, он и так не давит.
Speaker A
Задавай только, значит, important. Ну, важные как бы, да, замечания. Задавая только один вопрос клиенту в одном сообщении, совершая основную тему перед переходом к новой, запоминая, отвечая на несколько вопросов клиент по порядку. В конце каждого ответа вовлекай клиента в
Speaker A
разговор. Если клиент не задаёт вопрос или только здоровье, спрашивай, какой у вас вопрос. Если не знаешь, ответ на вопрос в базе знаний, сообщай, что на него ответит менеджер позже.
Speaker A
Если клиент из города, где нет возможности вживую посмотреть наши двери, спрашивает о наличии магазина, отвечает, что его регион доставка возможную компанию. Посмотреть двери может только, ну, на с шоурума нет. Но опять же здесь как бы можно вот это
Speaker A
вообще просто в файл базы знаний вывести. То есть зачем здесь это? Это можно отдельный файл базы знаний сделать, и он будет автоматом вызываться, когда клиент, ну, пишет про то, что у него нет возможности. Если наши возможности ограничены и то, что
Speaker A
спрашивает клиент у нас нет, предлагаю другие варианты. Ну вот здесь не очень понятно, какие другие варианты, то есть другие варианты чего вообще. То есть вот это предложение, ну такое себе. А определяй рабочее время менеджера. А опять же, в
Speaker A
какой момент всегда определять? Ну то есть в первую очередь, то есть ну не очень понятно. То есть определяя рабочее время менеджера, ну как бы лучше тогда вот это засунуть туда куда-то вот где нам нужно было его определить. Вот. Ну
Speaker A
вот как-то так. Давайте теперь вопросы ваши. А так, значит, сейчас Сергей, да, я отвечу.
Speaker A
Значит, почему бот отвечает на один и тот же вопрос? По-разному. Первый раз он отвечает как нужно правильно. Во второй раз в новом диалоге уже не следует инструкции.
Speaker A
А, ну, возможно, промт перегружен. Это первый момент. Хотя здесь он у вас не очень большой, но тем не менее. Второй момент, у вас стоит креативность. Вот если мы зайдём в доп настройки, посмотрим параметры ответа, видите, у вас стоит креативность. Если вы хотите
Speaker A
максимальную стабильность, ставите вот сюда стабильность. Если хотите, чтобы было что-то между, ставите сбалансированность. У вас стоит креативность. Это значит, что будет какая-то вариативность. Ну, знаете, вот есть разные типы клиентов, есть клиенты, которые говорят типа: "Блин, а что он
Speaker A
так отвечает всё время одинаково?" Ну, а вам не надо, чтобы он отвечал одинаково? Нет, но это же, типа, он же должен как-то типа разнообразно быть. Мы такие: "Ну, о'кей, ставьте креативность, будет вам отвечать по-разному". Вот.
Speaker A
Если хотите стабильности, вот переключайте в креативность именно, ну, креативность в стабильность. Значит, Александр Кононов. Просто каждый второй запрос касается стоимости при всех попытках оптимизировать. Бот, всё равно выходит накладно для организации, особенно с учёным, когда клиент часто пишет диалогов много. Но никто не
Speaker A
говорил, что использование AI агентов - это как бы дёшево. То есть это недёшево. Иногда это сопоставимо со стоимостью живых сотрудников. Да, такое бывает. Всё очень индивидуально, зависит от конкретной ситуации, от конкретной настройки. У нас есть отдельный блок с
Speaker A
лучшими практиками, и там есть отдельная как бы отдельный блок по оптимизации стоимости. Если вы его ещё не смотрели, то э ну кстати вот мой коллега, да, Рамиль вам, собственно, уже это отправил. Вот. То есть то есть, ну, посмотрите там, там как бы довольно
Speaker A
большой объём. На этом можно сделать вообще отдельный отдельный э вебинар. Может быть, мы его сделаем даже именно по оптимизации стоимости, но тут как бы там не так много способов, да? То есть самый главный способ - это уменьшение объёма информации, сокращение э промта,
Speaker A
сокращение базы знаний там и так далее. Как сокращать, выносить в подчинённых ботов, выносить в таблицы, ну, смотреть там и писать на английском сам пром. То есть, ну, я скажу так, что при правильной, мм, архитектуре бота можно привести стоимость диалога к нормальному
Speaker A
к нормальному ценнику. Но иногда, да, если диалоги слишком длинные, ну, как бы сорян, тут есть себестоимость, есть конечная стоимость, и это недёшево. Это это, ну, если мы начинаем, смотрите, какие ещё есть способы. У нас есть сейчас такая мысль, там задачка есть
Speaker A
одна, где мы хотим а-а оптимизировать ещё э стоимость за счёт а самаризации диалога. То есть, если, например, диалог слишком большой, начиная с определённого количества сообщений, мы просто берём его уменьшаем, то есть, ну, самаризируем. То есть мы его самаризируем и передаём уже
Speaker A
не всю историю, а только самари. Кстати, к вопросу о самозации, вот здесь есть ещё в параметрах ответов есть вот такой пункт передавать всю историю.
Speaker A
А, скорее всего, у вас стоит передавать всю историю, а вы можете поставить передавать историю, например, за X сообщений или за X минут. Это сокращает контекст, то есть историю диалога, и за счёт этого уменьшает его стоимость. Ну и ещё это вот сохранять историю вызова
Speaker A
функций. Если у вас там много функций, как вот в кейсах мы сегодня смотрели, то у вас тоже может быть там просто много функций вызывается, они каждый раз тянутся, эта история в диалоге, отключите эту галку, тоже может как бы
Speaker A
оптимизироваться. То есть, ну, как бы способов оптимизации их много. Надо просто прочитать руководство. Там каждый из них разобра довольно подробно. Если клиент написал размер проёма, бот всё равно переспрашивает: "А вы прислали размер проёма или полотна?" Не знаю, как
Speaker A
с этим быть. Как от него добиться, чтобы он читал, что клиент пишет, и не спрашивал, есть ли то, что уже известно, пока не прописал в инструкции, не вызывал он из базы знаний?
Speaker A
Ну, тут сложно сказать, как бы надо тут, да, путём тестов только можно определить как бы вот такие вещи. Иногда, да, приходится прописывать принудительно вызов файлов из базы знаний, чтобы, ну, вот как бы он конкретно понимал, что в этот конкретный момент это нужно делать,
Speaker A
потому что он каждый вопрос, он анализирует, смотрит на список, и как бы если там в файле базе знаний идёт какая-то, ну, типа неочевидность какая-то, идёт расхождение в рамках его понимания в его мозгов, да, мы тоже там не знаем, как он думает, почему вот он
Speaker A
одно считает одним, другое другим. Иногда даже банально это бывает трудности перевода. То есть иногда при переводе на английский одно и то же слово начинает иметь разные значения. То есть, например, слово реферат на русском, оно на английском звучит там
Speaker A
по-другому, там документ какой-нибудь. И когда человек на русском присылает реферат, то он уже в базе знаний это не находит, потому что для него реферат - это не документ, а это что-то как бы другое. И в этом случае иногда в базе
Speaker A
знаний, в том числе можно прописывать название на русском языке. Ну либо принудительно, что если клиент спрашивает о реферате, тогда вызывай вот этот файл базы знаний. Вот если стоимость вопроса в аналитике больше, чем стоимость ответа, это то это означает, что большая инструкция или
Speaker A
что-то ещё влияет на стоимость вопроса. Ну она всегда будет больше, чем стоимость ответа, потому что ответ - это просто ответ. Вот это набор, да, символов. А вопрос, когда мы отправляем в модель, мы же отправляем инструкцию, элементы базы знаний, информацию о всех
Speaker A
функциях, которые у нас подключены, там таблица, база знаний, эмсистемы и прочее. То есть там идёт большой объём такой как бы инструкции для него, ну, чтобы он понимал, как ему ответить.
Speaker A
Поэтому стоимость вопроса всегда больше всегда больше, чем чем стоимость ответа, потому что стоимость ответа она считается просто по токенум, а стоимость вопроса вот там как бы идёт э ну основной объём э ну как бы текста. Стиль общения и словарный запас бота зависит
Speaker A
от креативности бота. Стабильность может он там отвечает по шаблонам или нет. Да нет, тут скорее, смотрите, в чём вообще вот принцип работы вот этой креативности.
Speaker A
Это так называемая температура. Ну, есть такой параметр у LM моделей. Это означает, что вот а какое он будет выбирать. А, то есть, скажем так, чем меньше креативность, тем более популярная, аэ, более популярный ответ, то есть самый популярный ответ из своей внутренней
Speaker A
базы знаний и из того контекста, который мы ему подали, он будет выбирать. Ну, например, вот возьмём на простом примере, если я мы скажем кошка и, и вот здесь у каждого возникнет там кошка и мышка, кошка и собака, кошка и молоко,
Speaker A
например, да? Окажется, что молоко оно будет там на десятом месте по популярности, а, например, кошка и мышка, мышка оно будет на первом месте по популярности. Так вот, если клиент нам пишет как бы кошка и, то в случае стабильности, ну, если у нас вот эта
Speaker A
креативность стоит в в стабильности, всегда будет мышь. Всегда. То есть он всегда будет брать самое популярное слово, исходя из контекста. Если мы ставим, например, сбалансированность и креативность, то он, например, в 80% случаях будет брать мышка, а в 20%
Speaker A
остальных он будет выбирать какое-то рандомное. Он будет там второй популярности: кошка и собака, например, кошка и молоко, ну там и так далее, да?
Speaker A
То есть, понимаете, вот стабильность вот эта это по сути всегда самый популярный, самый точный ответ. типа вариативность там и, ну, там креативность и сбалансированность. Там уже будут туда залетать какие-то ситуации, где он будет разбавлять типовой вот такой, э, типовой
Speaker A
сценарий какими-то там дополнительными вопросами или его вопросы будут, ну, его ответы будут разнообразны от диалога к диа разнообразнее от диалога к диалогу.
Speaker A
Примерте привести, когда нужно сохранять историю функции, а когда не нужно. А, да, есть такой пример, например, если мы вызываем с вами Webхуhook, то есть, предположим, вот мы с вами используем, например, действия, и здесь в действии, например, мы делаем webhook. Мы
Speaker A
обращаемся на какой-то URL-адрес, например, в CRM систему и получаем из CRM-системы, например, 20 полей. 20 полей, в которых есть информация о доставке, не знаю, там, о наборе заказа, о, ээ, состоянии сборки. Ну, то есть 20 каких-то вот информации, 20 каких-то
Speaker A
ответов на вопросы. А клиент при этом у нас мог спросить типа: "А когда у меня вообще доставка, дата доставки?" И получается, что бот он как бы вот этот все вот эти 20 полей, этот ответ от функции, он будет при следующем запросе
Speaker A
клиента он его точно также будет как бы передавать в модель. Он будет его, ну, как бы вот эту историю хранить в себе, что я типа уже это делал. То есть, если клиент сначала спросила, когда у меня дата доставки, мы ему ответили, а потом
Speaker A
он спрашивает: "А у меня в заказе есть там полотенце или нет?" То в случае, если у нас история функции вызова, история вызова функции выключена, он сделает ещё один запрос на этот вебху, а, ну, чтобы получить эту информацию, потому что в истории у него этого уже не
Speaker A
будет. А если мы сохраним историю вызова функции, то у него он вот из этих двадцати полей, которые мы получили при первом запросе, он оттуда эту информацию найдёт. и сразу её предоставит, и ему не надо будет уже делать дополнительный
Speaker A
запрос на weбook и таким образом не тратит дополнительные токены, потому что в его истории как бы коммуникации, в его истории сообщений это уже информация есть. И тут надо смотреть вот, потому что от разного бывает, что дешевле выходит включать историю вызова функций,
Speaker A
а бывает, что дешевле её выключать. Тут всё зависит вот очень от, ну, конкретной ситуации, какие функции вы вызываете, какой объём эти функции возвращают, ну, нужно ли этот объём использовать повторно в диалоге или не нужно. И в зависимости от этого как бы уже это, ну,
Speaker A
можете, вы же можете протестировать, возьмите, включите её и проверьте диалог, потом выключите её и прогоните тот же самый диалог. Скорее всего, ну, вы сразу поймёте, где дешевле, где дороже.
Speaker A
А отключение истории вызова функции на что может повлиять? Например, функция заполнения полей и перехода на этапы вам, а не нужно же в историю тянуть. Мо могу безболезненно отключить историю. Ну да, да, можете, можете. Опять же другой пример. Например, предположим, а файл,
Speaker A
вызов файла базы знаний. Предположим, файл базы знаний называется доставка. Внутри файла базы знаний, например, есть огромная простыня по разным районам доставки. Вот как мы в примере сегодня разбирали у Виктории, там доставка была разбита на разные районы. А, предположим, что в не, ну, например, в
Speaker A
некоторых случаях взяли и для доставки сделали один файл, и внутри файла там уже информация о разных районах. Если у нас история вызова функции будет выключена, то когда человек спросит про один регион доставки, бот вызовет этот файл и как бы даст ему ответ. Когда он спросит
Speaker A
повторно, типа, а давайте, а, другой район сколько будет стоить? Он повторно вызовет этот файл базы знаний и как бы снова его обработает, снова даст ответ.
Speaker A
Это в случае, если история вызову функции выключена. Если она включена, то он уже не будет делать повторный вызов.
Speaker A
Зачем ему делать повторный вызов, когда у него в истории вызова функции эта информация уже есть? Он просто возьмёт из того файла, из своей истории и скажет: "Стоимость доставки столько-то, и в чате мы не увидим повторного вызова этой функции". Вот как это работает. И
Speaker A
тут вопрос, видите, тут зависит от того, а как у вас скомбинированы файлы базы знаний, содержат ли они какую-то повторяющуюся информацию, которую клиенту, может быть, понадобится или не содержит. Потому что если темп как бы эту информацию мы просто её взяли из
Speaker A
ответа пропихнули, ну, взяли из базы знаний, пропихнули в ответ, то вот ответы у него сохраняются сами, он из ответа эту информацию может подтянуть.
Speaker A
Но если там внутри файла базы знаний была информация гораздо больше, чем он дал в ответе, и эта информация может ему пригодиться в будущем, лучше, а, оставлять эту функцию включённой. Ну вот, кстати, ещё такой показательный пример, где точно нельзя выключать
Speaker A
историю вызова функции - это, например, а когда есть интеграция склалисом. Когда есть интеграция склалисом, там довольно много получается таких вызовов, последовательного вызова функций. И нам важно на каждом этапе, поскольку там внутри этих функций есть служебная информация, всякие служебные
Speaker A
идентификаторы. Нам эти идентификаторы нужно как бы знать. Мы их в ответе не даём, но внутри чата они для нас имеют определённое значение, и нам важно, чтобы они вот сохранялись на всю историю чата. Вот. Ну, надеюсь, я как бы здесь
Speaker A
подробно объяснил по каждому из вопросов. Давайте ещё последний вопрос. Готов ответить и будем закругляться.
Speaker A
Сегодня, как всегда, получилось довольно продуктивно. Значит вот аэ давайте два вопроса Игоря и Алёны и всё. А у вас база знаний и таблицы в векторном формате в итоге сохраняются?
Speaker A
База знаний в вектором формате сохраняется в разделе вот в разделе, который называется большие файлы. То есть вот если мы откроем раздел базы знаний, вот здесь есть отдельный раздел большие файлы. Вот этот - это векторный формат. Вот он как бы работает как бы
Speaker A
как классический рак. Таблицы тоже могут сохраняться в векторном формате, но для этого используется вот отдельный как бы режим работы с таблицей, вызов таблицы через действия. В этом случае тоже можно искать путём векторного сравнения по таблице. Как это делается, ну, лучше
Speaker A
посмотреть в в руководстве. Я сейчас вам скину ссылку на руководство именно по таблице и, э, собственно, посмотрите там.
Speaker A
Значит, а Алёна спрашивает: "Верно, я понимаю, что если у меня авторизация в боте через номер телефона, то в случае отключения функции бот в следующий раз будет запрашивать телефон у клиента, чтобы его снова авторизовать для получения ответов".
Speaker A
Ой, ну не очень понятно, если честно, потому что клиент он как этот номер телефона, если он его присылает в чате, то как бы и у вас есть некая процедура авторизации. Ну да, тогда как бы скорее всего, если у вас эта авторизация проверяется
Speaker A
при каждом обращении клиента, ну, наверное, да. Ну, честно говоря, затрудняюсь здесь ответить. Боюсь просто, а, вам не дать не неправильный ответ. Надо смотреть именно вашу структуру более подробно. Приходите на следующий разбор или напишите в поддержку, обязательно разберёмся. Всё,
Speaker A
друзья, мне кажется, на сегодня э хватит. А буду рад, если вы, мм, значит буду рад, если вы поставите свой комментарий, а-а, пальчики вверх, плюсики, сердечки и в целом дадите обратную связь. было ли полезно для вас этот формат? Потому что для меня, у
Speaker A
меня, честно говоря, глаз немножко замылился, да, он, ну, когда ты каждый день с этим работаешь и понимаешь, как это устроено, то, мм, ну, немножко происходит такая, как это, профессиональная деформация, да, ты уже не понимаешь, где понятно, где непонятно, интересен этот формат, не
Speaker A
интересен, есть от него польза или нет. Поэтому ваши комментарии, они всегда дают обратную связь: полезно это, не полезно, придёте ещё или не придёте.
Speaker A
Вот. Спасибо. Было продуктивно и полезно. Супер. Спасибо. Польза есть. Полезно. Прийдём ещё. Супер. Хорошо. Тогда м я думаю, что на сегодня а а да, ну, согласен, да. Поэтому и делаем, собственно, эти форматы. А тогда м будет запись этого вебинара. Кто хочет
Speaker A
присмотреть, э, мы выложим их на наших ресурсах на Ютубе, на Рутубе и на ВК видео. А всем большое спасибо за вопросы, за участие. Это очень радует, что вы так классно вовлечены в этот процесс. И увидимся на следующих эфирах.
Topics:промптыAI-ботыпродажиискусственный интеллектчат-ботавтоматизация коммуникацийстроительная компаниянастройка ботовструктура промтаэффективность ботов
