RAG_helper/docs/OPTIMIZATION_CONVERSION_v1.md

Оптимизация конверсии ветки new_booking — предложение спринта

Дата: 2026-04-27 Автор предложения: по результатам сравнения песочницы с действующим ботом-конкурентом «Александра» (NEXTBOT) на сайте ЛОР-клиники. Куда встраивать: между Спринтом 7 (мульти-RAG, часть A) и Спринтом 8 (мини-eval). Желательно до eval — чтобы baseline в eval/reports/ уже отражал новую воронку, а не старую.

---

1. Контекст и причина

На реальной воронке клиники (виджет на сайте) пациент пишет жалобу один раз и хочет либо получить полезный ответ, либо записаться. Каждая «промежуточная» реплика бота — потеря части лидов: пациент закрывает виджет, идёт искать на других сайтах, или просто перестаёт отвечать.

Контрольный кейс — стандартный вход «Здравствуйте! очень сильно храплю, иногда закладывает уши». На том же кейсе:

Параметр	Конкурент (NEXTBOT/Александра)	Наш прототип
Количество реплик бота до запроса телефона	2	3
Количество реплик пациента до запроса телефона	2 (жалоба → «хочу»)	2 (жалоба → имя)
Медицинская гипотеза в первом ответе	Да: перегородка / аденоиды / ринит	Нет
Рекомендация специалиста в первом ответе	Да: ЛОР-врач	Нет
Услуга и цена в первом ответе	Да: эндоскопия, 1000 ₽	Нет
Явный CTA на запись в первом ответе	Да: «Хотите, чтобы я помогла записаться?»	Нет
Имя пациента	Спрашивается вместе с телефоном (один шаг)	Спрашивается отдельным шагом (intro)

Главные содержательные различия — два:

1. Конкурент сразу решает задачу пациента, а потом продаёт запись. Мы сначала собираем анкету, а суть жалобы откладываем.
2. Конкурент укладывает обмен в 4 реплики (бот → пациент → бот → пациент), мы — в 6+. Каждая лишняя итерация — это и доп. токены, и доп. drop-off.

Нынешняя архитектура new_booking (intro → qualify → present → offer_time → book → close) полностью валидна для оператора, который ведёт пациента по записи. Проблема не в графе, а в содержимом первого осмысленного ответа и в порядке сбора слотов name и phone.

2. Цель спринта

Сделать воронку new_booking сопоставимой с конкурентом по конверсии при сохранении нашей архитектуры (state machine, слоты, защитные условия, soft-insertion). Конкретно — переписать содержание шагов intro и qualify, поменять момент сбора имени, добавить в qualify обязательную «содержательную обвязку» (гипотеза + специалист + услуга + цена + CTA).

3. Целевые метрики (для ручной проверки и mini-eval)

• Сжатие воронки. На контрольном кейсе «храп + заложенность ушей» количество реплик бота до момента, когда у нас в слотах phone ≠ null, должно быть ≤ 3 (сейчас ~5).
• Содержательность первого ответа. На любую входную реплику с явной ЛОР-жалобой первый осмысленный ответ бота должен покрывать пять пунктов:
  • короткое сочувствие в одну фразу,
  • 2–3 возможные ЛОР-причины формулировкой «может быть связано с»,
  • рекомендация специалиста,
  • упоминание профильной услуги и цены (эндоскопия / аудиограмма / приём — то, что есть в вики и применимо к жалобе),
  • бинарный CTA «записать вас на приём?».
• Сохранение защитных условий. Все 8 ручных сценариев из блока H Спринта 6b продолжают проходить (запись ребёнка, листы ожидания, эскалация, routing_loop). Новая воронка не ломает существующие guard'ы.
• Сохранение тона. Тёплое обращение, «вы», без диагнозов, без дозировок — все правила базового промпта new_booking.md остаются.

4. Что меняем — обзор

Изменения локальные: четыре файла промптов и один JSON intent_steps.allowed_next (таблица переходов). Кода трогаем минимум.

Файл	Что меняем
prompts/intents/new_booking/steps/intro.md	Урезаем до одной короткой реплики приветствия + инициирующего вопроса. Снимаем требование собрать name именно здесь.
prompts/intents/new_booking/steps/qualify.md	Добавляем обязательный шаблон «содержательного ответа на жалобу»: гипотеза → специалист → услуга/цена → CTA. Имя становится опциональным слотом.
prompts/intents/new_booking/steps/present.md	Сокращаем до одной фразы-подтверждения (если вообще оставляем — обсуждаемо).
prompts/intents/new_booking/steps/book.md	Запрос телефона + имени в одной реплике; имя становится частью контактного блока, а не отдельной анкетой.
intent_steps.allowed_next (сид + миграция данных)	Разрешаем intro → book напрямую при коротком пути «есть жалоба + согласие» (см. блок A).

5. Блоки задач

Блок A. Сжатие воронки и перестановка сбора имени

Промпты:

• intro.md — переписать. Новая задача шага: поздороваться одной фразой и сразу спросить, чем можем помочь, не запрашивая имя. Текст приветствия — «Здравствуйте! Я виртуальный ассистент клиники. Расскажите, что вас беспокоит — подскажу, к какому специалисту записаться.» Слот name со шага intro снимаем (становится опциональным, заполняется на qualify или book).
• book.md — переписать запрос контакта: «Чтобы администратор связался с вами и подтвердил время — напишите ваш номер телефона и как к вам обращаться». В одной реплике собираем phone и (опционально, если ещё не собрано) name. Если пациент назвал имя раньше — повторно не спрашиваем.
• qualify.md — снять требование «не уходи дальше пока нет name», т.к. имя теперь не обязательно для перехода с intro и собирается естественно по ходу.

Таблица переходов (intent_steps.allowed_next):

• Расширить allowed_next шага intro: добавить переход intro → qualify (как сейчас) и новый прямой intro → present на случай, когда пациент уже первой репликой назвал и жалобу, и согласие записаться (редкий, но возможный случай).
• Подтвердить, что qualify → book через present остаётся, а сам present мы либо радикально сокращаем (см. блок C), либо удаляем как самостоятельный шаг.

UI-чекпойнт A:

• В «Песочнице» прогнать кейс «Здравствуйте, болит ухо» — на первой реплике бот не спрашивает имя, а сразу даёт содержательный ответ (это уже эффект блока B).
• В «Песочнице» прогнать кейс «Здравствуйте, я Сергей, болит ухо, хочу записаться» — слот name=Сергей подхватывается на qualify, на book имя повторно не спрашивается.
• Что проверяем глазами: общее число реплик бота до запроса телефона — 3 или меньше. В timeline переходов нет «зависания» на intro.

Блок B. Содержательный qualify — гипотеза, специалист, услуга, цена, CTA

Промпты:

• qualify.md — добавить обязательный шаблон ответа на первую реплику с жалобой. Шаблон в системном промпте шага описывается как пять пунктов в строгом порядке:
  1. Эмпатия — одна фраза («Понимаю, это действительно может мешать»).
  2. Гипотеза — 2–3 возможные ЛОР-причины формулировкой «может быть связано с» (без диагноза). Источник причин — RAG из подписанных документов ветки (Спринт 7), при отсутствии подходящего чанка — общая фраза без конкретики.
  3. Специалист — рекомендация по профилю жалобы (ЛОР, сурдолог и т. д.).
  4. Услуга и цена — упомянуть профильную услугу, которую врач может назначить на приёме, с ценой из вики, формулировкой «при необходимости назначит». Цена — отдельным предложением, чтобы не выглядело как «обязаны заплатить».
  5. CTA — бинарный вопрос: «Записать вас на приём?» / «Хотите, я помогу записаться?».
• В qualify.md зафиксировать: если пациент сразу ответил «да/хочу/записывайте» — переход qualify → present (или qualify → book напрямую, если решим в блоке C сокращать present). Слот reason фиксируем по тексту жалобы, specialist — по выводу гипотезы.
• Сохранить все три «особые ситуации» (ребёнок, конкретный врач, первичная жалоба на слух) — они срабатывают как сейчас и не конфликтуют с новым шаблоном (просто добавляются в логику ответа).

RAG (зависимость от Спринта 7):

• Подписать на ветку new_booking документы вики, содержащие связки «жалоба → возможные причины → специалист → услуга → цена». Если на момент Спринта документов нет — завести задачу для Натальи: подготовить wiki-страницы по 5–7 типовым жалобам (храп, заложенность ушей, боль в горле, тугоухость, насморк, головокружение, шум в ушах) в формате «жалоба → 2–3 ЛОР-причины → специалист → процедура и цена».
• Для жалоб, не покрытых вики, шаблон деградирует мягко: эмпатия + рекомендация ЛОР-врача + CTA, без гипотез и услуги. Это лучше, чем выдумывать.

UI-чекпойнт B:

• В «Песочнице» прогнать 5 контрольных кейсов: храп + уши, боль в горле, тугоухость, насморк > месяца, звон в ушах. На каждом — первый ответ бота должен содержать все 5 пунктов шаблона (или явно деградировать на 3, если документа в подписке нет).
• В отладочной панели «Найденные фрагменты» — видно, какие чанки пошли в гипотезу/услугу.
• Что проверяем глазами: на контрольном кейсе из раздела 1 наш ответ субъективно «не хуже» ответа Александры. Можно показать ответы рядом и сравнить.

Блок C. Сокращение или удаление шага present

Решение требует обсуждения перед началом работ:

Вариант 1 (минимальное вмешательство): оставить present как есть, но переписать на одну короткую фразу-подтверждение («{name?}, оформляю запись к {specialist}, на приёме врач уделит внимание {reason}»). Сразу после — переход на book (запрос контакта), без отдельного шага offer_time для текущей итерации воронки.

Вариант 2 (агрессивный): убрать present как самостоятельный шаг. Подтверждение плана зашить в первую фразу book («Записываю к {specialist}. Чтобы администратор связался — телефон и имя?»). Тогда воронка: intro → qualify → book → close, всего 4 шага вместо 6.

Аргументы за вариант 2: ровно так делает конкурент (сразу после «Хочу» — запрос телефона). Каждый шаг — это +1 реплика бота, и present без нового действия от пациента ощущается как «вода».

Аргументы за вариант 1: меньше риска сломать ручные сценарии 1–8 из Спринта 6b, проще откатить, шаг present остаётся точкой, куда возвращаемся при пересогласовании специалиста.

Предлагаю вариант 2 с явным фолбэком: если на ручных кейсах пациенты теряют ощущение, что их услышали, — возвращаем present обратно в граф.

Задачи (для варианта 2):

• present.md — пометить как deprecated в рамках спринта, не удалять файл (история).
• book.md — добавить в начало шаблон одной фразы-подтверждения с использованием слотов specialist и reason.
• Миграция intent_steps: убрать present из allowed_next шага qualify, добавить прямой переход qualify → book. Шаг present оставить в таблице как «висящий» на случай отката.
• Обновить prompts/intents/new_booking/transitions.yaml (если есть) или соответствующий сид.

UI-чекпойнт C:

• Прогнать в «Песочнице» все 8 сценариев Спринта 6b. Сценарии 7 (ребёнок) и 8 (конкретный врач) — проверить отдельно, что guard'ы и waitlist-рукав не сломались.
• Что проверяем глазами: базовый кейс из раздела 1 закрывается за 4 реплики бота вместо 6. Ручной сценарий 7 (ребёнок) — guard require_legal_rep всё ещё блокирует переход.

Блок D. Тест-кейсы и регрессия

Подготовка eval-набора (заготовка для Спринта 8):

• В eval/MANUAL_CASES.md добавить раздел «Конверсионные кейсы» с 5 контрольными жалобами из блока B. Для каждого — ожидаемые слоты после первой реплики пациента, ожидаемая структура первого ответа бота (проверяется глазами по чек-листу из 5 пунктов), ожидаемое количество реплик до сбора phone.
• Добавить негативный кейс: «Здравствуйте» (без жалобы) — бот должен задать открытый вопрос, не уйти в шаблон гипотезы (т. к. нет reason).
• Добавить кейс с быстрой записью: «Запишите меня к ЛОРу на завтра» — бот должен пропустить блок гипотезы (жалоба не описана) и сразу подтвердить + спросить контакт.

Проверка отсутствия регрессии:

• Все 8 сценариев из блока H Спринта 6b проходят без правок ожиданий.
• eval/router_cases.csv — accuracy не упала. Особое внимание: на кейсах с жалобами роутер по-прежнему возвращает new_booking, а не medical_question (наш sticky state machine это страхует, но всё равно проверяем).
• Soft-insertion (Спринт 6b блок D) работает: «а сколько стоит приём?» внутри новой короткой воронки — отвечается на месте, шаг не сбрасывается.

6. Принятые компромиссы и риски

• Цены в первом ответе. Чтобы упоминать цену, нужен корректный документ в RAG. Если документа нет — бот не выдумывает, и тогда первый ответ без цены и без гипотез — просто эмпатия + специалист + CTA. Это всё ещё лучше текущего «как к вам обращаться?», но без цены воронка слабее. Прогресс по этому риску напрямую зависит от качества вики (задача Натальи).
• Имя пациента может потеряться. Если пациент не назвал имя ни на intro (где мы его теперь не спрашиваем), ни на book, в слот name останется пустым. Это нормально — name всё равно опциональное поле для вежливого обращения, а не идентификатор. На book спрашиваем явно, поэтому шанс потерять минимальный.
• Subjective trade-off: тон. Перенос имени с intro на book ощущается «менее персонально» в первой реплике. Компенсируем содержательностью ответа — пациент видит, что бот понял его проблему, и это сильнее, чем «как к вам обращаться?».
• Конкурент тоже не идеален. Александра упоминает цену на эндоскопию, но не предлагает её альтернативы и не уточняет жалобу. Это окей для нашего MVP, но в бэклог стоит внести задачу «варьировать услугу по типу жалобы» (для тугоухости — аудиограмма, не эндоскопия).

7. Критерий готовности спринта

• На контрольном кейсе раздела 1 наш бот в «Песочнице» отвечает по 5-пунктовому шаблону, и весь обмен до запроса телефона укладывается в 3 реплики бота.
• Все 8 ручных сценариев из блока H Спринта 6b проходят без правок ожиданий.
• 5 контрольных конверсионных кейсов из блока D добавлены в eval/MANUAL_CASES.md и прогнаны вручную; результаты — в eval/MANUAL_REPORT.md.
• Промпты intro.md, qualify.md, book.md обновлены, изменения видны во вкладке «Шаги» (Спринт 6a, блок A) — оператор может прочитать без выгрузки кода.
• Если выбран вариант 2 блока C — миграция таблицы переходов выполнена, present помечен как deprecated.

8. Что НЕ делаем в этом спринте

• Не трогаем _router.md — изменения локальные внутри ветки.
• Не делаем confidence threshold для RAG (это в бэклоге, нужно после прогона eval).
• Не пишем CRM-интеграцию (мок-инструменты crm.create_booking — отдельный пункт бэклога).
• Не трогаем шаги offer_time и close — они внутренние, конкурент их вообще не показывает в первой воронке. Их роль (выбор времени из календаря и финал) станет актуальна, когда подключим реальный календарь в Спринте 9 / при подключении канала.

9. Дальнейшие идеи (на потом)

• Вариация услуги по жалобе. Сейчас предлагаем стандартную эндоскопию. После наполнения вики — научить ветку выбирать профильную процедуру по reason (тугоухость → аудиограмма, насморк > 4 недель → риноскопия и т. д.). Это требует отдельного слота suggested_procedure и подсказки в промпте qualify.
• A/B тестирование двух версий первого ответа. После Спринта 8 (eval) запустить две версии qualify параллельно и сравнить, какая даёт лучшее покрытие 5-пунктового шаблона на ручных кейсах.
• Постпродажа на close. После сбора телефона — короткое «также можем напомнить за день до приёма SMS» / «оставить второй контакт для родственника». Конкурент этого не делает; это не догоняние, а попытка обогнать. Завести в идеи только после стабилизации основной воронки.

---

Зависимости:

• Спринт 6a (вкладка «Шаги», структурированный выход) — должен быть закрыт до старта этого спринта, иначе править промпты шагов через UI не получится.
• Спринт 7 (мульти-RAG) — желателен закрытым, чтобы цены и услуги попадали в qualify через подписки документов. При незакрытом 7 спринт делаем на устаревшем механизме «вся коллекция», результат будет хуже.

Оценка трудозатрат (в условных единицах):

• Блок A (промпты + переходы): 1 день.
• Блок B (содержательный qualify + RAG-увязка): 1.5 дня. Зависит от готовности вики.
• Блок C (вариант 2): 0.5 дня.
• Блок D (eval-кейсы): 1 день.
• Итого: ~3–4 дня инженерного времени + ~2 дня Натальи на вики (параллельно).