Диалог в разговорном ИИ устроен как повторяющийся цикл: ассистент получает реплику, понимает намерение и данные в ней, обновляет запись о состоянии диалога, решает, что делать (ответить, спросить, выполнить действие, отказаться или позвать человека), и только потом формулирует ответ. Языковая модель участвует в понимании и в формулировке, но память, правила и действия лежат вне неё.
Такое разделение нужно ради проверяемости. Если модели отдано всё, ассистент выглядит гибким, но при ошибке нельзя сказать, где она случилась. Услуга описана на странице «Разговорный ИИ и виртуальные ассистенты», здесь только устройство и способ проверки.
Три способа построить диалог и когда какой брать
Диалоговые системы строят тремя основными способами. На практике их смешивают: жёсткая схема там, где цена ошибки высока, свободная модель там, где вопросы разнообразны.
| Способ | Как работает | Где силён | Где ломается | Когда брать |
|---|---|---|---|---|
| Сценарий по схеме | Заранее нарисованное дерево шагов, на каждом кнопки или ожидаемые слова | Предсказуем, легко проверить, не придумывает | Любое отклонение от схемы приводит к тупику или возврату в начало | Короткие процедуры с высокой ценой ошибки: платёж, смена данных, запись |
| Заполнение полей | Для задачи задан список нужных данных (дата, номер, адрес). Модель достаёт их из свободного текста, сценарий спрашивает недостающее | Принимает фразы в любом порядке, ведёт к цели, данные проверяются | Хуже работает, когда задач много и они пересекаются | Заявки, записи, анкеты, статусы |
| Свободная модель с инструментами | Модель сама решает, какой инструмент вызвать (поиск, запрос в систему), и ведёт разговор | Гибко отвечает на разнообразные вопросы, хорошо работает по документам | Сложнее проверять, возможны ошибки в выборе действия и выдуманные факты | Вопросы по базе знаний, помощь сотрудникам, черновики ответов |
Типичная рабочая схема гибридная: свободный диалог по документам с ссылкой на источник, а для действий (запись, статус, заявка) включается заполнение полей с подтверждением. Права ассистента на действия разобраны в статье «Как ограничить ИИ-агента», отличие от простого бота — в статье «Чем ИИ-агент отличается от чат-бота».
Ход диалога на условном примере
Условный пример: ассистент записывает клиента на консультацию. Таблица показывает, что происходит на каждой реплике и что остаётся в записи о состоянии. Пример учебный, не описание чьего-то проекта.
| Реплика | Что делает система | Что в состоянии после реплики |
|---|---|---|
| «Хочу записаться на консультацию» | Определяет намерение «запись», запускает сценарий, видит, что нет ни даты, ни темы | Намерение: запись. Заполнено: ничего. Не хватает: тема, дата |
| «По договору поставки, лучше во вторник» | Достаёт тему и день недели, сверяет с расписанием, находит два свободных времени | Тема: договор поставки. Предпочтение: вторник. Предложены два слота |
| «А сколько это стоит?» | Видит смену темы, отвечает из прайса со ссылкой на документ и возвращает к записи | Запись не сброшена; вопрос о цене отмечен как отвеченный |
| «Давайте второе» | Раскрывает «второе» по предыдущей реплике, повторяет дату и время, просит подтвердить | Слот выбран, ожидается подтверждение |
| «Да» | Создаёт запись в системе, проверяет ответ системы, отправляет подтверждение | Запись создана, идентификатор сохранён, сценарий завершён |
Обратите внимание на третью реплику. Если бы ассистент хранил состояние только в переписке, смена темы легко стёрла бы запись. Отдельное состояние позволяет ответить и вернуться. Ответ из прайса строится по найденным фрагментам ваших документов; как устроен такой поиск, описано в статье «Что такое RAG».
Память диалога: что помнить, а что забыть
У разговорного ИИ есть три вида памяти. Путать их — частая причина странного поведения.
- Контекст текущего обращения. Последние реплики, которые передаются модели вместе с вопросом. Окно ограничено, поэтому в длинной переписке начало вытесняется. Решение: хранить краткое изложение ранней части и ключевые параметры отдельно.
- Состояние сценария. Что собрано, чего не хватает, на каком шаге мы находимся. Живёт в базе под идентификатором диалога и переживает перезапуск сервиса. У состояния есть срок: если человек вернулся через неделю, старые параметры лучше подтвердить, а не подставить.
- Сведения о клиенте и сотруднике. Берутся из CRM и учёта по подтверждённому идентификатору в момент, когда нужны, и не копируются в диалог навсегда.
Что не стоит помнить вообще: пароли, номера карт, документы, не нужные для сценария. Если человек прислал их сам, ассистент не повторяет их в ответе и не хранит в журнале. Персональные данные граждан России обычно должны храниться на серверах в России, а срок хранения журнала записывается заранее. Юридическую сторону определяет юрист заказчика, мы закладываем технические меры.
Уточнения и ремонт диалога
Диалог ломается чаще всего не на сложных вопросах, а на мелких сбоях понимания. Хороший ассистент их замечает и исправляет, не требуя начинать заново.
| Что случилось | Плохая реакция | Хорошая реакция |
|---|---|---|
| Не хватает данных | Угадывает значение или молчит | Задаёт один вопрос, при небольшом числе вариантов перечисляет их |
| Реплика неоднозначна: «отмените» | Отменяет первое, что нашёл | Спрашивает, что именно: заказ, запись или подписку |
| Человек исправляет себя: «нет, не вторник, среду» | Продолжает со вторником или начинает сначала | Меняет одно значение в состоянии и подтверждает новое |
| Смена темы посреди сценария | Сбрасывает собранное или игнорирует вопрос | Отвечает на новый вопрос и предлагает вернуться |
| Два уточнения подряд не помогли | Задаёт третье, четвёртое, пятое | Предлагает оператора или другой способ связи |
| Просьба, которой нет в возможностях | Придумывает ответ | Говорит, что этого не умеет, и называет, что умеет |
Два правила держим всегда. Подтверждение важных значений (сумма, дата, адрес, номер) стоит одной реплики, а исправление ошибки в записи стоит заметно дороже. И слова «стоп», «не надо», «хочу человека» работают на любом шаге без дополнительных вопросов.
Когда ассистент зовёт человека
Передача оператору — часть диалога, а не его провал. Правило передачи записывается заранее, иначе ассистент либо передаёт слишком часто, либо упорствует там, где пора остановиться. Запускать передачу стоит по пяти причинам:
- человек сам просит оператора;
- тема в списке тем, которые ассистент не решает (деньги, претензии, юридические вопросы, здоровье);
- уверенность в ответе ниже порога, выбор которого разобран в статье «Порог уверенности модели»;
- два уточнения подряд не привели к результату;
- тон диалога ухудшается: повторы, жалоба, резкие слова.
Не менее важно, что получает оператор. Он должен видеть краткое изложение диалога, собранные параметры, найденные источники и причину передачи, иначе клиент пересказывает всё заново, и передача только раздражает. Ещё нужно решить, что видит клиент: когда его возьмут в работу и что делать, если оператор сейчас недоступен. Если ответа не будет до утра, ассистент так и говорит и принимает заявку. Связь с карточкой клиента и дубли описаны в статье «Как подключить чат-бот к CRM».
Защита диалога от обмана и утечек
Диалог — открытая дверь в систему: любой человек может написать в неё что угодно. Поэтому рядом с моделью стоят проверки.
- Права на стороне сервера. Ассистент выполняет действия от имени пользователя и только в пределах его прав. Просьба «выдай данные другого клиента» упирается в проверку, а не в вежливость модели.
- Инструкции отделены от реплик. Попытки «забудь предыдущие указания» должны не работать. Как это устроено, разобрано в статье про prompt injection.
- Источники ограничены. Ассистент отвечает по документам, к которым у вопрошающего есть доступ. Закрытый регламент не должен попасть в ответ новичку.
- Журнал. Реплики, найденные источники и выполненные действия записываются. Без журнала нельзя разбирать спорные диалоги.
Для данных ограниченного доступа внешний программный интерфейс облачной модели чаще не подходит по требованиям заказчика, и тогда модель разворачивается на ваших серверах.
Как проверить диалог до запуска
Проверка отдельных ответов не показывает, будет ли работать диалог: ошибка часто возникает на третьей-четвёртой реплике. Поэтому тестируют диалоги целиком.
Что нужно для проверки
- Набор диалогов. Обезличенные реальные переписки вашей линии с отметкой итога. Выдуманные примеры дают приятную, но ложную картину.
- Критерий приёмки. Что считается успехом: сценарий доведён до результата, ответ подтверждён источником, передача оператору была обоснованной. Значения согласуются с вами до начала.
- Трудные случаи отдельно. Опечатки, две просьбы в одной реплике, исправление себя, смена темы, попытка обойти правила.
- Прогон при каждом изменении. Новая модель, новая инструкция, обновлённая база знаний запускают набор заново. Ухудшение показателя означает отказ в принятии изменения.
Где проверка обманывает
- Оценивают по одной реплике, а ошибка в состоянии видна только в конце диалога.
- Доверяют оценке одной модели другой модели без выборочной проверки человеком: такой «судья» бывает необъективен к собственному стилю.
- Набор диалогов составлен авторами сценария и содержит только то, что они предусмотрели.
- Считают только долю закрытых диалогов, не глядя на ошибочные закрытия: «решено» и «человек сдался» выглядят в журнале одинаково, пока их не разметят.
Промпты и инструкции тоже версионируются и проверяются; метод описан в статье «Prompt-engineering для бизнеса». Если диалог идёт голосом, добавляются распознавание речи и задержки: это в статье «Как устроен голосовой ИИ-ассистент».
Ошибки, которые встречаются чаще всего
- Состояние хранится только в переписке. Любая длинная беседа или перезапуск ломает сценарий.
- Нет пути к человеку. Ассистент зацикливается, а клиент уходит в другой канал.
- Ассистент отвечает без источника. Проверить ответ невозможно, а ошибка выглядит уверенно.
- Слишком много тем сразу. Запуск со всеми вопросами разом не позволяет понять, что работает. Начинают с одной-двух тем.
- Манера речи не описана примерами. Ответы то слишком сухие, то слишком разговорные, то обещают лишнее.
- Нет разбора диалогов после запуска. Пробелы в базе знаний и неудачные сценарии накапливаются, потому что их никто не читает.
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели, если ассистенту нужны база знаний, CRM и система заявок одновременно. На выходе выбранные сценарии, набор диалогов для проверки, правила передачи человеку, права ассистента и вилка бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.
Дальше лёгкий пилот (150 000–400 000 ₽, 2–8 недель) на одном канале или тяжёлый, если ассистент должен выполнять действия в ваших системах. На любой ступени можно остановиться: сделанное остаётся у вас по акту, исходники лежат в вашем репозитории с первого коммита. Мы не обещаем ассистента, отвечающего на любой вопрос, не принимаем решения о деньгах вместо человека и не дежурим круглосуточно. Цены и сроки — на странице «Тарифы», описание услуги — на странице «Разговорный ИИ и виртуальные ассистенты».
Частые вопросы
Чем память ассистента отличается от контекста модели?
Контекст — это текст, который передаётся модели вместе с вопросом, и он ограничен по размеру. Память ассистента шире: состояние сценария в базе, краткое изложение ранней части переписки и сведения из ваших систем, которые подтягиваются по запросу. Надёжным считается то, что записано в базе, а не то, что модель помнит из переписки.
Нужно ли дообучать модель, чтобы она вела диалог?
Обычно нет. Сначала настраиваются инструкции, поиск по документам, состояние и правила передачи. Дообучение рассматривается, только если после этого остаются стабильные ошибки в манере или терминах, и решение принимается по результатам проверки на ваших диалогах.
Сколько уточняющих вопросов допустимо?
Один вопрос за раз и не больше двух подряд по одной недостающей детали. Если два уточнения не помогли, ассистент предлагает оператора или другой способ связи. Допрос из пяти вопросов раздражает сильнее, чем честная передача.
Как ассистент понимает, что тема сменилась?
Модель определяет намерение каждой реплики, а сценарий сравнивает его с текущим. Если новое намерение не относится к начатому сценарию, ассистент отвечает на вопрос и предлагает вернуться, не сбрасывая собранные данные. Это проверяется отдельным тестом на смену темы.
Можно ли обойтись без языковой модели?
Можно, если вопросы предсказуемы и укладываются в меню или правила. Модель нужна там, где формулировки разнообразны и ответы лежат в документах. Часто модель включают только в понимание и формулировку, а решения оставляют за правилами.
Как проверить, что ассистент не раскрывает чужие данные?
Тестом из-под разных ролей: просим данные другого клиента, закрытый регламент, служебные инструкции, пробуем фразы вида «забудь предыдущие указания». Права проверяет сервер, а не модель, поэтому успешность таких попыток должна быть нулевой, а каждый случай разбирается как ошибка.
Сколько стоит разработка диалогового ассистента?
Обследование — 200 000 ₽ за один-два процесса или 350 000 ₽ при нескольких системах. Лёгкий пилот стоит 150 000–400 000 ₽ за 2–8 недель, тяжёлый (с действиями в системах) — 400 000–1 200 000 ₽ за 2–3 месяца. Вывод в эксплуатацию начинается от 1 500 000 ₽ этапами по 300 000–700 000 ₽.
Что делать, если у нас нет записанных диалогов?
Начать с их сбора: в переписках с клиентами, обращениях в поддержку и вопросах сотрудников по почте. Часть набора можно составить вместе с вашими сотрудниками, но он должен отражать реальные формулировки. На обследовании мы обычно сначала смотрим, что уже есть, и честно говорим, хватит ли этого для проверки.