Обсуждение — ИИ чат-поддержка на сайте через свой VPS

Прочитала с точки зрения того, кто сидит по ту сторону кнопки «позвать оператора». У меня ночные смены в саппорте (не здесь), и больше всего зацепило место про эскалацию.

В статье бот отвечает круглосуточно, а при неуверенности зовёт оператора или показывает форму заявки. Днём это понятно. А в три часа ночи оператором бывает один человек на всё, а то и никого. Клиент нажал кнопку, увидел «соединяем» и ждёт. По-моему, хуже этого только бот, который уверенно ответил неправильно.

Второе. В разделе про гибкость сказано, что диалог передаётся живому оператору с полной историей. Но в примере /ask принимает один text и возвращает один answer: ни сессии, ни сохранения переписки. Для минимального примера это нормально, просто историю придётся где-то хранить отдельно, иначе оператор получит клиента без контекста. Тогда первым делом он спросит «опишите проблему», и клиент начнёт заново с того же места, где застрял с ботом. Это самый частый повод для злых отзывов, которые я разбираю утром.

Отсюда вопрос к тем, кто такое собирал: что вы делаете с кнопкой ночью? Честно пишете «оператор будет с 9:00, оставьте контакт», скрываете кнопку или держите дежурного? И как отдаёте человеку историю: целиком, или бот сам делает короткую выжимку? Выжимке я бы, кстати, не очень доверяла, она может пересказать мимо сути.

polina_smena писал:
историю придётся где-то хранить отдельно, иначе оператор получит клиента без контекста

Согласен. Добавлю, что с этим хранилищем стоит решить заранее, а не после первой жалобы.

В переписку с ботом люди пишут всё подряд: телефон, номер заказа, адрес, иногда пароль от личного кабинета, раз уж спросили «что не работает». Пока /ask ничего не запоминает, этого добра на сервере нет. Как только появляется таблица с сессиями, оно оседает там и попадает в бэкапы, а бэкапы обычно живут дольше и лежат дальше от глаз, чем основная база.

До того как прикручивать историю, я бы ответил на три вопроса. Сколько хранить: оператору утром нужна ночная переписка, а полугодовой архив, скорее всего, нет. Кто видит: оператор, все сотрудники или ещё и тот, кто разбирает логи модели. Как удалять: если запись чистится по сроку в базе, но остаётся в недельных копиях, это стоит понимать и учитывать.

Насчёт ночной кнопки мне ближе ваш первый вариант. Честное «ответим с 9:00, оставьте контакт» плюс уже сохранённая история. Утром оператор открывает заявку, видит, на чём клиент застрял, и пишет ему первым. Кнопка «соединяем», за которой никого нет, хуже честного ожидания. Тем более что клиент запомнит и её, и тишину после.

nesterov писал:
В переписку с ботом люди пишут всё подряд: телефон, номер заказа, адрес, иногда пароль от личного кабинета

К этому списку я бы добавил то, что у нас пишут, когда платят криптой. С картами у нас сложно, поэтому USDT для многих обычный рабочий способ. Человек перевёл, деньги не видны, он нервничает и вставляет в чат всё подряд: хеш транзакции, адрес кошелька, скриншот приложения целиком. Хеш и адрес ещё ладно, они и так видны в блокчейне. А на скриншоте бывает видно баланс, а иногда и открытая фраза восстановления, потому что человек не понял, что именно у него просят. Если кошелёк потом опустеет, такую переписку уже не удалишь задним числом.

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

Регулярки, конечно, всё не поймают, особенно картинки. Но лучше пусть бот лишний раз попросит человека не присылать лишнего, чем такая запись потом полгода лежит в недельных бэкапах )

farid_tash писал:
до вопроса «сколько хранить» я бы поставил ещё один: что вообще не записывать

Согласен, только «записывать» происходит не в одном месте. Сегодня вечером рисовал себе схему такого бота, и точек записи там оказалось три.

Сайт → бэкенд с /ask → шлюз на несколько моделей → провайдер модели.

Первая точка — таблица с историей, про неё вы уже написали. Вторая — сам шлюз. Он почти всегда логирует запросы, чтобы считать токены и разбирать ошибки, и в лог может попасть всё тело сообщения целиком. Третья — внешний провайдер: что он хранит у себя, решаете уже не вы.

Поэтому фильтр на сид-фразы и номера карт я бы ставил не перед сохранением истории, а перед отправкой в шлюз, то есть до любой записи. Если моделей несколько, одно правило на входе шлюза удобнее, чем отдельная проверка в каждой интеграции. А в настройках шлюза стоит отдельно найти, можно ли не писать текст запросов, а только метаданные: модель, токены, время, код ответа. Для отладки этого обычно хватает.

Со скриншотами хуже, регулярка картинку не прочитает. Если модель принимает изображения, кошелёк с открытой фразой улетит провайдеру раньше любого фильтра. Я бы ночью вообще не пропускал картинки к модели: сохранял файл локально с коротким сроком жизни и отдавал оператору утром. Если, конечно, сохранять его вообще нужно.

kostya_gw писал:
Со скриншотами хуже, регулярка картинку не прочитает.

С картинками я бы не просто закрывал вход, а сразу давал человеку, куда деть доказательство. У нас так: если карта не прошла и платишь криптой, первым делом скринишь приложение и ищешь, кому показать. Это почти рефлекс. Двоюродный брат в такой ситуации однажды отправил в чат магазина скрин целиком, вместе с балансом и именем, просто потому что поле для файла было прямо под рукой.

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

С картами то же самое. Достаточно последних четырёх цифр и времени операции, а не фото экрана с выпиской.

И ещё один плюс: форму проще пропустить через фильтр перед шлюзом, чем свободный текст. Хеш проверяется по формату, сумма — число, а всё лишнее туда просто некуда вписать.

arsen_evn писал:
сеть, сумма, хеш, примерное время

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

timur_ufa писал:
сеть это чё, название биржи?)

Нет, это блокчейн, по которому шли USDT: TRC20, ERC20, BEP20 и другие. В деталях перевода она обычно подписана «Сеть» или «Network». Знакомый спросил меня то же самое, а потом оказалось, что он сам выбирал её при выводе и не заметил. Выпадашка — да, но только с сетями, которые магазин реально принимает, плюс пункт «не знаю». По формату хеша сеть часто можно угадать и без человека.

По хешу TRC20 от ERC20 отличишь: у второго 0x. А ERC20 и BEP20 выглядят одинаково, тут только искать в обоих эксплорерах. Пункт «не знаю» я бы нажал первым.

andrei_brest писал:
Пункт «не знаю» я бы нажал первым.

Пусть после «не знаю» бэкенд сам ищет транзакцию в обоих эксплорерах, хеш всё равно публичный. Только проверяйте длину, а не одно 0x. У хеша 64 hex-символа, у адреса кошелька 40, и люди их постоянно путают. Поле, которое принимает что угодно с 0x в начале, быстро станет тем же свободным текстом, куда кто-нибудь вставит фразу восстановления. Строгий формат тут работает как фильтр.

n1kita писал:
Строгий формат тут работает как фильтр.

Работает, если поле объясняет отказ. У меня студенты сдают треки через форму, которая молча отбивает не тот формат. Итог: в почте один трек трижды, последний называется mix_final_REAL.wav. Сам когда-то так диплом сдавал, каюсь.
С хешем так же. На 40 символах лучше сразу сказать: «похоже на адрес кошелька, нужен хеш перевода, он длиннее». Иначе человек решит, что форма сломалась, и пойдёт в чат со скрином.

robert_sound писал:
Иначе человек решит, что форма сломалась

У гостей ровно так. Летом поле телефона в брони молча не принимало номер с пробелами, и люди шли в WhatsApp: «у вас сайт не работает, вот мои данные». Сразу присылали фото паспорта, хотя я его ни разу не просила. Добавили под полем одну строчку «можно с пробелами», и паспортов в мессенджере стало заметно меньше. Сейчас ноябрь, гостей мало, как раз время перечитать такие подписи.

yulia_sochi писал:
Добавили под полем одну строчку «можно с пробелами»

блин, а можно ведь пойти дальше и вообще не спорить с человеком из-за пробелов. Пусть бэкенд сам их вырежет, а ругается только тогда, когда реально не то. Ща набросал, как это выглядело бы для хеша:

import re

def clean_hash(raw):
    s = re.sub(r"\s", "", raw).lower()
    body = s[2:] if s.startswith("0x") else s
    if re.fullmatch(r"[0-9a-f]{64}", body):
        return body, None
    if re.fullmatch(r"[0-9a-f]{40}", body):
        return None, "Похоже на адрес кошелька. Нужен хеш перевода, он длиннее"
    return None, "Хеш — 64 символа: цифры и буквы a–f"

Пробелы, перенос строки при копировании, 0x есть или нет — всё это молча проглатывается. Отказ получают только адрес вместо хеша и откровенная каша. Это минимальный набросок: сеть он не определяет, эксплореры не дёргает.

И один момент, на котором я сам чуть не споткнулся: отбитое значение не надо писать в лог «для отладки». Если кто-то вставил в поле двенадцать слов, они как раз и окажутся в отказах. Для отладки хватит «отказ: не тот формат, длина 87».

У тебя с телефоном то же самое было бы: убрать пробелы, скобки и дефисы, и подпись под полем, может, вообще не понадобилась бы))

tema_py писал:
отбитое значение не надо писать в лог «для отладки»

На WP лог часто пишешь не ты. Плагин форм бывает сохраняет каждую отправку в базу, отказы тоже. А включённый WP_DEBUG_LOG по умолчанию кладёт debug.log в wp-content, и без отдельного запрета его можно открыть из браузера. Я теперь на каждом клиентском сайте первым делом смотрю, что хранит плагин форм и где лежит лог, а уже потом читаю код.

ira_sites писал:
На WP лог часто пишешь не ты.

В чате поддержки ещё проще: там вся переписка уже лог. На прошлой смене клиент вставил мне пароль от кабинета, «чтобы быстрее». Теперь он лежит в тикете, а я могу его только скрыть, не удалить. Если ставить на сайт ИИ-чат, я бы сначала выяснила, где хранятся диалоги и кто их потом читает. Обычно читает кто-то вроде меня, в четыре утра и одним открытым глазом.

timur_ufa, у нас крипта обычно запасной вариант на случай, когда карта не прошла. Биржевое приложение человек открывает раз в пару месяцев, и сеть ищет так же, как ты. Я бы научил ИИ-чат не просить скрин перевода. На скрине из приложения часто видно баланс, почту и соседние переводы, и всё это остаётся в логе диалогов. Пусть лучше спросит хеш и подскажет, где в деталях операции строка «Сеть».

arsen_evn, если чат идёт через шлюз, скрин осядет ещё и в логах прокси, и у провайдера модели. Я бы на шлюзе просто не пускал картинки в этот чат.

arsen_evn писал:
Пусть лучше спросит хеш и подскажет, где в деталях операции строка «Сеть».

Подсказка должна быть такой же узкой, как подпись у Юлии. Я раньше просил студентов «пришлите настройки экспорта». Приходил скрин всего экрана: проект, почта, чат с мамой. Теперь пишу: «три значения: частота, битность, формат». Приходят три значения.
Боту стоит спрашивать так же, одним полем. Сам однажды скинул коллеге скрин микшера вместе с перепиской о зарплате. Слух хороший, зрение подвело.

robert_sound писал:
Боту стоит спрашивать так же, одним полем.

Узкий вопрос снижает шанс, но не обнуляет. Кто-то всё равно вставит двенадцать слов в поле хеша. Тогда важно, что бот ответит. Худший вариант — вежливо переспросить «вы прислали: ...» и ещё раз записать фразу в историю. Лучше без повтора: «похоже на фразу восстановления, она открывает кошелёк, никому её не отправляйте». Диалог пометить для человека. Скрыть сообщение мало: фраза уже ушла в логи и к модели.