Майя Буто

Да, у меня в этой версии был один общий порог для всех категорий. Сам score при этом собирался из нескольких признаков: категория имела самый большой вес, дальше учитывались возрастной диапазон, зона, теги, подкатегория, наличие фото до/после и приоритет кейса. Если лучший результат не проходил общий порог, система фиксировала case_match_found=false и передавала заявку без кейса.
Ваш пример с окрашиванием и уходом как раз показывает место, которое я бы сейчас пересмотрела: один threshold удобен как стартовая модель, но если распределение совпадений сильно отличается между категориями, логичнее выносить порог в конфигурацию категории, а не держать его глобальным. У меня в той версии до category-specific thresholds дело не дошло, поэтому не хочу придумывать — был именно один общий порог.

Да, по факту у нас роли были разделены довольно жёстко. Новые кейсы в базу заводила сама владелица салона — именно у неё были права на использование фотографий и все необходимые согласия. Администратор эту базу не редактировал вообще. Workflow только читал активные кейсы и выполнял подбор. Если подходящий кейс не проходил порог, система явно фиксировала, что кейс не найден, и передавала заявку дальше без него, чтобы это не выглядело как сбой. Администратор подключался уже после handoff: получал структурированную заявку и дальше связывался с клиентом. Если требовалась консультация специалиста, он уже передавал заявку соответствующему специалисту. А отдельного жёстко заданного срока, за который новый кейс должен был попасть в active, в этом проекте не было — это не было формализовано как SLA.

Да, именно. Поиск по истории хорошо отвечает на вопрос «что и где было сказано», но для следующего действия этого недостаточно — нужно отдельно понимать текущее подтверждённое состояние. И мне нравится ваша формулировка через структурированное поле со значением, датой и источником: тогда переписка остаётся журналом изменений, а действующее условие живёт отдельно и может быть проверено перед действием. По сути, здесь уже важны не столько поиск по истории, сколько управление текущим состоянием и происхождением данных: что сейчас считается действующим значением и на каком основании.

Да, согласна — это вообще не только про AI. Проблема появляется в любом процессе, где важные условия живут прямо в переписке: там легко одновременно существуют несколько версий договорённостей, а сама история сообщений не говорит, какая из них сейчас действующая. Для меня переписка — это скорее лог изменений, а текущее подтверждённое состояние должно фиксироваться отдельно. AI здесь просто делает этот класс ошибок заметнее: он может очень быстро найти старый факт и использовать его как актуальный. Поэтому главный вопрос уже не «что было сказано в переписке», а «какое состояние сейчас считается подтверждённым для следующего действия».

Да, именно поэтому я и не стала добавлять versioning в V1 «заодно». На уровне идеи это выглядит как простая новая версия объекта, но дальше сразу появляются вопросы: какой snapshot считать актуальным, как хранить историю изменений, что делать с уже сформированными PDF и как не потерять связь между версиями.
Поэтому в текущей версии я сначала зафиксировала надёжный approval-flow, а versioning оставила отдельным следующим слоем.
Спасибо за обратную связь — приятно, что вы тоже увидели именно эту границу.

Спасибо :) Да, проценты специально не придумывала — если эффект отдельно не измерялся, лучше так и написать.
По approve: в текущей V1 snapshot не разлочивается. Пока объект в IN_REVIEW, менеджер может проверить расчёт, добавить/удалить позиции и внести корректировки. После APPROVED создаётся locked snapshot, и утверждённое состояние остаётся неизменным — в том числе если потом меняются ставки в каталоге. Мы это отдельно проверяли: старый approved snapshot сохранил прежнюю ставку и сумму, а новый draft уже посчитался по изменённой ставке. Механизм «исправить уже утверждённый объект и получить новую ревизию» в V1 я сознательно не добавляла. Это отдельный versioning-сценарий: старая approved-версия должна остаться неизменной, а правка — создавать новую версию с новым approval/snapshot. У меня это вынесено в отдельный следующий модуль, потому что он затрагивает историю, snapshots и PDF.
По AppSheet: на тех объёмах, которые реально были в проекте, заметного торможения я не увидела. В одном из контрольных состояний базы было 65 объектов, 87 зон и 219 строк выбранных работ/материалов. Внутри отдельных замеров при этом было больше 25 позиций работ и материалов, распределённых по нескольким зонам.
Кроме этого, система отдельно хранила окна и двери как проёмы, а также фото и эскизы как вложения — мы загружали их в разные объекты и привязывали к соответствующим зонам/работам. То есть нагрузка была не только от списка работ, а от связанного набора сущностей: объект → зоны → работы/материалы → проёмы → вложения.
На таком фактически проверенном объёме приложение работало нормально, без заметных лагов. Поэтому конкретный порог «после N объектов AppSheet начинает тормозить» я бы пока не называла — до него в этом проекте просто не дошли. Но на фактически проверенном объёме проблем с производительностью именно из-за количества объектов/работ не было.

Да, именно. И здесь для меня есть ещё один нюанс: эталоном не обязательно должна быть одна жёстко заданная последовательность шагов. В некоторых agentic-сценариях к правильному результату можно прийти несколькими допустимыми маршрутами. Поэтому я бы фиксировала не только ожидаемую последовательность, но и сам контракт run: обязательные decision points, допустимые tools и аргументы, запрещённые действия, handoff- и approval-boundaries. Тогда можно проверить не просто «получился ли тот же ответ», а прошла ли система допустимую траекторию и не нарушила ли ограничения. И если один и тот же сценарий прогоняется после смены prompt, routing или модели, уже видно, что именно изменилось.
По сути это как раз то, что я имела в виду выше под превращением удачной конфигурации в воспроизводимый контракт.

Да, согласна: считать только количество диалогов, закрытых без человека, здесь было бы поверхностно. В моём случае ценность как раз не в максимальном вытеснении администратора, а в том, чтобы до передачи уже собрать и сохранить контекст и не заставлять клиента повторять то, что он сообщил раньше. В workflow состояние диалога хранится отдельно: уже собранные поля не должны теряться при следующем сообщении, а после handoff лид блокируется от повторного прохождения обычной квалификации. Если клиент уже после передачи уточняет новый телефон или Telegram, это обрабатывается как отдельное обновление контакта и администратору приходит отдельное уведомление, а не начинается новый диалог с нуля.
Интересна ваша мысль про стоимость возвратов. В этом проекте я такую метрику не считала, но сам показатель «сколько обращений возвращается из-за потери контекста / повторных вопросов» действительно намного полезнее простого числа автоматизированных диалогов.

Спасибо, вы как раз попали в важное место системы.
Передача администратору у меня идёт не просто как «новая заявка», а уже со структурированным контекстом: категория и подкатегория запроса, цель клиента, возраст, зона, как давно беспокоит проблема, что уже пробовали, контакт, удобное время связи, причина handoff, needs_human, температура лида, последний ответ AI и, если был найден, подобранный кейс. Отдельно формируется рекомендация администратору, что делать дальше. То есть ему не нужно восстанавливать суть диалога из всей переписки. По базе кейсов: она отдельная от диалога. Система берёт только активные кейсы нужной категории и дальше считает соответствие по категории, возрастному диапазону, зоне, тегам, подкатегории, наличию фото «до/после» и приоритету. Если порог не набран, кейс автоматически не показывается и заявка уходит без него. Сама база кейсов сейчас управляется как отдельный справочник — новые работы туда добавляются/обновляются отдельно, а workflow только читает её и выбирает наиболее подходящий кейс.

По конверсии «из 100 диалогов в заявку» у меня нет корректной цифры — в этом кейсе я не проводила отдельный статистический замер на такой выборке, поэтому здесь не хочу придумывать метрику.
А вот handoff у меня был не по простому списку ключевых слов вроде «цена» или «запись». Система сначала ведёт qualification flow: категория → возраст → зона → длительность → что уже пробовали → контакт → удобное время. После этого переходит к case matching и готовой передаче. Отдельно есть needs_human: если человек просит живого специалиста или появляются медицинские/чувствительные темы — противопоказания, беременность, осложнения, аллергия, сильная боль, воспаление, требования гарантии и т.п. — система уходит в human handoff.
Причём если handoff нужен, но контакта ещё нет, она сначала дособирает контакт и только потом передаёт администратору.
Насчёт шести полей согласна: если собирать их как анкету подряд, можно потерять человека. Поэтому у меня это не форма из шести вопросов сразу, а последовательный диалог по недостающим данным.