Параметры в Glagol: опции и правила простыми словами
Параметр в Glagol — это поле, в котором агент хранит информацию о текущем диалоге: что нужно клиенту, как его зовут, на что он согласился и какой шаг уже выполнен.
Представьте администратора, который разговаривает с клиентом и заполняет карточку. Клиент назвал имя — администратор записал его. Попросил узнать цену — отметил цель обращения. Согласился записаться — перешёл к оформлению. Параметры помогают ИИ-агенту работать похожим образом.
Начнём с короткого примера:
Клиент: «Хочу записаться на занятие».
Агент: «Как к вам обращаться?»
Чтобы настроить такой переход, нужно связать три вещи:
| Что настраиваем | Пример | За что отвечает |
|---|---|---|
| Параметр | Причина обращения | Какую информацию храним |
| Опцию | Хочет записаться | Какой вариант определён |
| Правило | Если хочет записаться и имя ещё не спрашивали — спросить имя | Что сделать дальше |
Параметр — поле в карточке. Опция — вариант его состояния. Правило — инструкция, как действовать с учётом этого состояния.
Что такое опции параметра
У одного параметра может быть несколько опций. Например, для «Причины обращения» настроим такие варианты:
| Номер | Как понимаем состояние в этом примере |
|---|---|
| 0 | Причина ещё не определена |
| 1 | Хочет записаться |
| 2 | Хочет узнать стоимость |
| 3 | Хочет поговорить с сотрудником |
Когда настроенный механизм распознаёт просьбу о записи, текущей становится опция 1. Если распознаёт вопрос о цене — опция 2.
Активация опции означает, что параметр перешёл в соответствующее состояние. Например, «активировалась опция “Хочет записаться”» — это просто «в карточке отмечено, что клиент хочет записаться».
Набор опций зависит от задачи: для причины обращения нужны одни варианты, для согласия — другие. Номера опций используются в настройках условий и переключений.
Опция 0 — когда ответ ещё не известен
У обычного параметра в редакторе есть служебная опция 0, или default. Её удобно понимать как исходное состояние: «пока не знаем» или «ещё не заполнено».
Для параметра «Согласие на запись» полезно различать три ситуации:
| Состояние | Что произошло |
|---|---|
| Пока неизвестно | Клиент ещё не дал понятного ответа |
| Согласен | Клиент подтвердил желание записаться |
| Отказался | Клиент явно отказался |
Отсутствие согласия ещё не означает отказ. Благодаря отдельным состояниям агент сможет уточнить ответ, а не завершить разговор раньше времени.
Как параметры встраиваются в правила
Правило состоит из условий и действий.
Условие проверяет, что уже известно: «Клиент хочет записаться?» или «Ответ с именем уже получен?».
Действие определяет следующий шаг: задать вопрос, выполнить настроенный запрос или изменить состояние другого параметра.
Например:
ЕСЛИ клиент хочет записаться И имя ещё не спрашивали,
ТО произнести «Как к вам обращаться?» и отметить этап «Ждём имя».
В этом правиле параметры используются дважды: сначала агент проверяет их, затем меняет этап разговора.
flowchart TD
A["Ответ клиента"] --> B["Настроенная обработка ответа"]
B --> C["Текущее состояние параметров"]
C --> D["Условия правил"]
D --> E["Действия подходящего правила"]
E -->|"Переключение параметра"| C
E -->|"Ответ клиенту"| F["Настроенная фраза"]
Схема показывает связь настроек: параметры влияют на выбор правил, а действия правил могут менять параметры. Например, после вопроса об имени агент отмечает, что теперь ожидает ответ именно на этот вопрос.
Условие «клиент согласился» проверяет согласие. Действие «установить согласие» записывает его. Чтобы проверить реальный ответ клиента, нужна первая настройка.
Какие сведения можно хранить в параметрах
В сценарии записи на занятие параметры могут выполнять разные задачи:
| Для чего нужен параметр | Пример |
|---|---|
| Помнить данные клиента | Имя, удобное время |
| Понимать запрос | Запись, вопрос о цене, просьба позвать сотрудника |
| Хранить ответ на предложение | Согласен, отказался, просит объяснить подробнее |
| Отмечать этап разговора | Ждём имя, уточняем время |
| Фиксировать результат действия | Заявка отправлена, отправка завершилась ошибкой |
Это задачи, для которых вы создаёте параметры. А способ их заполнения выбирается через тип опции: по словам, с помощью ИИ, сохранением ответа или другим доступным способом.
Состояние и сохранённое значение — разные вещи
Допустим, агент спросил имя и получил ответ «Анна».
Ему полезно знать сразу две вещи:
| Что хранит параметр | Пример |
|---|---|
| Текущее состояние | Ответ получен |
| Конкретное значение | Анна |
Для следующего клиента состояние тоже будет «Ответ получен», а значение — «Игорь». Создавать отдельную опцию для каждого имени не нужно.
В настройках и технических данных эти части называются:
-
decide — номер текущей опции, например 1.
-
show — сохранённое значение, например «Анна».
У опции с заранее заданным значением в show может быть подпись «Хочет записаться». У опции, которая сохраняет ответ, значение появляется во время разговора.
Как выбрать тип опции в Glagol
Задайте себе вопрос: откуда агент должен получить эту информацию?
| Что нужно сделать | Какой тип выбрать | Что настраивается |
|---|---|---|
| Узнать знакомые слова и выражения | Поиск по словам | Словари, по которым проверяется ответ |
| Разобраться в смысле разных формулировок | LLM-выбор | Инструкция для ИИ и модель LLM |
| Сохранить сам ответ | Ответ | Контекст, в котором его нужно сохранить |
| Отметить этап или выполненный шаг | Флаг | Действие, которое переключает параметр |
| Проверить текст определённого формата | Регулярное выражение | Шаблон проверки текста |
Для первых сценариев обычно достаточно разобраться в первых четырёх вариантах.
Поиск по словам — узнаём знакомые выражения
Чтобы распознавать просьбу о записи, можно подготовить словарь с формулировками «хочу записаться», «запишите меня», «можно записаться» и подключить его к опции.
Словарь собирает разные выражения, которые в вашем сценарии должны означать одно и то же.
Подписи опции недостаточно. Если назвать её «Хочет записаться», но не настроить способ активации, агент не получит инструкции, как распознавать это желание.
Учитывайте отрицания и неоднозначные фразы. «Не хочу записываться» нельзя обрабатывать как просьбу о записи только из-за знакомого слова.
LLM-выбор — распознаём смысл с помощью ИИ
Человек может сказать: «Мне бы попробовать у вас позаниматься, как попасть на первый урок?» Для такого разнообразия формулировок можно использовать языковую модель — LLM.
Опции задают понятную инструкцию. Например:
Выбирай «Хочет записаться», когда клиент просит оформить запись или попасть на занятие. Не выбирай эту опцию, если он только спрашивает цену или прямо отказывается от записи.
В настройках параметра нужно выбрать модель LLM. Полезно описать и признаки нужного ответа, и близкие ситуации, которые к нему не относятся.
Ответ — сохраняем реплику
Тип «Ответ» помещает в параметр ответ собеседника или системы.
Если человек сказал «Анна», можно сохранить «Анна». Если он ответил «Меня зовут Анна, я уже звонила вчера», сохранение реплики само по себе не выделит из неё только имя. Для этого нужна отдельная обработка, например с помощью ИИ.
Используйте этот тип, когда нужен исходный текст ответа. Когда нужен конкретный факт из длинной реплики, предусмотрите его извлечение.
Флаг — отмечаем состояние
Флаг подходит для отметок вроде «Приветствие произнесено» или «Ждём имя». Такой параметр можно переключить действием правила.
Например, правило произносит вопрос и устанавливает этап «Ждём имя». Следующее правило проверяет этот этап, прежде чем обработать ответ.
Флаг помогает помнить ход сценария; самостоятельный поиск слов ему не нужен.
Почему важно понимать, на какой вопрос отвечает клиент
Слово «да» само по себе почти ничего не объясняет. Его смысл зависит от вопроса:
| Агент спросил | Клиент ответил | Что нужно отметить |
|---|---|---|
| «Хотите записаться?» | Да | Согласие на запись |
| «Вам удобно сейчас говорить?» | Да | Можно продолжить разговор |
| «У вас остались вопросы?» | Да | У клиента есть следующий вопрос |
Поэтому параметру нужно задать контекст работы — в какой части разговора он должен обрабатывать ответ.
В интерфейсе для этого есть «Слушаемые фразы» и «Слушаемые правила»:
-
Плюс — где параметр должен работать.
-
Минус — какие фразы или правила исключить.
-
Слушать везде — включить все фразы или правила соответствующей категории.
Здесь выбираются настроенные фразы и правила агента. Выражения клиента, которые нужно распознавать, задаются отдельно — например, в словарях.
Дополнительно у опции можно задать условия активации. Например: сохранять ответ на вопрос об имени только при состоянии «Ждём имя» у параметра «Этап записи».
| Настройка | Какой вопрос решает |
|---|---|
| Условие активации опции | Можно ли сейчас изменить состояние этого параметра? |
| Условие правила | Можно ли сейчас выполнить это действие? |
Пример настройки параметров — спрашиваем имя клиента
Соберём небольшой фрагмент диалога. Клиент уже сказал, что хочет записаться. Агент должен спросить имя, сохранить ответ и перейти к уточнению времени.
В этом учебном примере сохраняется реплика целиком. Проверку того, что человек действительно назвал имя, а не задал встречный вопрос, настраивают отдельно.
Шаг 1. Создайте три параметра
| Параметр | Опции в нашем примере |
|---|---|
| Причина обращения | 0 — ещё не определена; 1 — хочет записаться |
| Этап записи | 0 — имя ещё не спрашивали; 1 — ждём имя; 2 — перешли к вопросу о времени |
| Ответ на вопрос об имени | 0 — ответа нет; 1 — опция типа «Ответ» |
Расшифровки опции 0 здесь объясняют её смысл для сценария. В редакторе это служебный default.
Для рабочих опций «Этапа записи» используйте «Флаг». Для определения причины обращения настройте, например, «Поиск по словам» или «LLM-выбор».
У опции типа «Ответ» подпись в редакторе фиксирована — «Реплика собеседника». В этом примере её активация будет означать, что ответ на вопрос об имени получен.
Шаг 2. Создайте правило, которое спросит имя
ЕСЛИ причина обращения — «Хочет записаться» И этап — «Имя ещё не спрашивали»,
ТО произнести «Как к вам обращаться?» и переключить этап на «Ждём имя».
У правила должны быть оба действия: фраза и переключение параметра. Проверка этапа не даст задавать этот вопрос заново только потому, что клиент всё ещё хочет записаться.
Шаг 3. Настройте сохранение ответа
В параметре «Ответ на вопрос об имени»:
-
Для опции 1 выберите тип «Ответ».
-
Настройте слушаемые фразы или правила для шага с вопросом об имени.
-
В условиях активации этой опции укажите: «Этап записи» — «Ждём имя».
Теперь сохранение ответа связано с нужным участком разговора.
Шаг 4. Создайте правило следующего вопроса
ЕСЛИ этап — «Ждём имя» И в параметре «Ответ на вопрос об имени» активна опция 1,
ТО спросить «В какое время вам удобно заниматься?» и переключить этап на «Перешли к вопросу о времени».
Посмотрим, как заполняется карточка:
| Что произошло | Этап записи | Сохранённый ответ |
|---|---|---|
| Клиент попросил записать его | Имя ещё не спрашивали | Ответа нет |
| Агент спросил имя | Ждём имя | Ответа нет |
| Клиент сказал «Анна» | Ждём имя | Анна |
| Следующее правило задало вопрос о времени | Перешли к вопросу о времени | Анна |
Чтобы действительно создать запись во внешней системе, нужно отдельно настроить запрос к ней и обработку результата.
Дополнительные типы опций
Данные и сложные проверки
Регулярное выражение проверяет текст по заданному шаблону. Например, подходит ли указанный код под нужный формат. Такой тип полезен для формальных проверок; писать сложные шаблоны для первого сценария необязательно.
JSON предназначен для структурированных данных — набора полей, например сведений о заявке. Значение отображается в отчётах как форматированный JSON. Откуда поступают данные, настраивается отдельно: например, из ответа внешнего сервиса.
Комбинация условий объединяет проверки текста и источника реплики. Например: ответ пришёл от собеседника И содержит выражение из выбранного словаря. Можно использовать поиск по словам, регулярные выражения и проверку источника со связками И, ИЛИ, НЕ, РОВНО ОДНО, НИ ОДНОГО.
События диалога и служебные значения
Для нестандартных ситуаций в Glagol есть дополнительные типы. Они помогают отметить событие, на которое затем может отреагировать правило.
| Тип опции | Когда пригодится |
|---|---|
| Нет правил | Не найдено подходящее правило |
| Пустой ответ | Получен пустой ответ |
| Ответ не изменил параметры | После обработки ответа параметры не изменились |
| Параметры не изменились | Нет изменений после применения правила и анализа ответа |
| Повтор правила | Одно правило повторяется больше заданного числа раз |
| Диалог завершён | Нужна обработка после завершения диалога в звонковом режиме |
| Следующая фраза | Нужно передать следующую фразу для озвучивания при соответствующей привязке |
| UUID | Нужно отреагировать на специальный идентификатор UUID в ответе |
| Скрытые данные | Нужно скрыть чувствительное значение в отчётах |
| Мужчина / Женщина | Подключённая система распознавания речи предоставляет результат определения пола |
Например, «Пустой ответ» позволяет выделить отдельную ситуацию. Чтобы агент после неё переспросил, нужно настроить соответствующее правило и фразу.
Для очередей запросов есть специальный тип параметра API Queue: он создаётся парой связанных параметров — запросов и статуса. Его используют при настройке интеграций; для примера со сбором имени он не нужен.
Как избежать частых ошибок
| Если сделать так | Что может пойти не так | Как настроить правильно |
|---|---|---|
| Написать только название опции | Ответ не будет распознаваться по одной подписи | Настроить её тип и способ активации |
| Считать «не согласился» отказом | Исходное состояние тоже попадёт под это условие | Проверять отдельную опцию отказа |
| Сохранять имя при любой реплике | Вместо имени запишется вопрос о цене | Ограничить контекст и при необходимости добавить извлечение имени |
| Записать ответ в параметр и ждать озвучивания | Текст сохранится, но это не операция речи | Настроить фразу в правиле |
| Отметить «Заявка отправлена» до результата запроса | В карточке появится неподтверждённый успех | Менять итоговое состояние после проверки результата |
| Сбрасывать все параметры после каждой реплики | Потеряются уже полученные данные | Сбрасывать только временные результаты, нужные для нового шага |
Частые вопросы о параметрах Glagol
Можно ли использовать один параметр в нескольких правилах?
Да. Например, «Причину обращения» могут проверять разные правила: одно начинает запись, другое отвечает о цене. Каждому правилу задаются свои условия и действия.
Может ли параметр заполняться без ИИ?
Да. Для этого подходят поиск по словам, регулярные выражения, сохранение ответа и переключение правилом. LLM-выбор — один из доступных способов.
Может ли значение прийти не от клиента?
Да. Например, из настроенного API-запроса — обращения к внешнему сервису — или программного модуля. Правило также может переключить параметр на нужную опцию.
Где посмотреть результат работы параметров?
Параметры используются в отчётах. В настройках можно включить показ нужного параметра в бизнес-отчёте и задать его позицию. Так менеджер увидит, например, причину обращения и собранные данные без поиска по всему разговору.
Как проверить первый сценарий?
Пройдите его как клиент. Сначала дайте ожидаемый ответ, затем попробуйте другую формулировку, отказ и встречный вопрос. Для каждого варианта проверьте две вещи: что сохранилось в параметре и какое правило выполнилось.
Для начала достаточно одного вопроса: что агент должен запомнить, как он это узнает и что сделает после ответа? Эти три решения помогают собрать первый понятный фрагмент сценария.