Что запрашивать, у кого и в каком порядке, чтобы получить возможность выгружать
диалоги, аудиозаписи и технические логи звонков. Состояние на 08.09: разбор реальных обзвонов идёт
через Voice360, все четыре входа — Kibana и PVS на ИФТ и ПРОМ — получены к 08.09,
остальное решили не запрашивать. На ИФТ текста реплик в логах нет, полная картина звонка — на ПРОМ.
Сверху — инструкция целиком, ниже — схема связей и пояснения к ней.
Инструкция
🎯Цель
Регулярно выгружать диалоги и записи для разбора звонков
По конкретному дефекту доходить до «что реально ушло в модель»
🧭Решение 08.09 — что берём, что нетвопрос доступов в основном закрыт
Берём. Voice360 — все ПРОМ-диалоги с кодом завершения и записью, доступ есть, им уже пользуемся. PVS IVR на ПРОМ — учётки Kibana (07.09) и PVS (08.09) получены: даёт то, чего нет в выгрузке (ниже). Стенд TTS — для ошибок, которые воспроизводятся на стенде: баг на стенде плюс ссылка в чат GigaVoice. Для ошибок в сессии GigaVoice команда просит форму: контур, greenfield, session_id и аудио с обеими сторонами (раздел «Стенд TTS»)
Не запрашиваем. Grafana, СМД как источник логов, Elastic по API, Dumper, пермишены GigaVoice. Логи GigaChat отложены: мост от звонка к request-id не доказан, а по багу «функция без текста» команда GigaChat после первых ответов замолчала — предъявлять логи некому. Обход бага уже в промпте: двухходовое завершение
Что мы хотим от технических логов IVR (это не коды — коды видны в Voice360 как «Результат звонка»): кто завершил звонок — disconnect положил IVR, far положил клиент, transfer перевод (показано); тексты, ушедшие в TTS, — чтобы отличить обрыв на синтезе от короткого ответа модели (показано; сырого ответа модели в логах IVR нет); тайминги по ходам для измерения пауз (длительность запросов показана, паузы между репликами считать по временным меткам — проверить); код завершения как переданное в IVR значение (предположение: сам вызов dialog_end внутри GigaVoice в логах IVR не виден — проверить)
PVS и Kibana — два окна в одни данные. Логи лежат в Elasticsearch (ИФТ — Delta, ПРОМ — Омега). Kibana показывает сырые записи с временем и полями, PVS группирует их по сессии и показывает запросы и ответы, длительности, завершение и UUID. Смотреть через PVS, в Kibana ходить за точными метками и полями, которых PVS не показывает
Отдельная дорожка Кости — витрины в Омеге и данные клиентов (ПКАП ММБ, уровни доверия, история взаимодействия) для персонализации и оцифровки эффективности. К диагностике звонков не относится; он проходит доступы первым и расскажет
⚠️ Voice360 не идеален: часть диалогов не транскрибируется, часть — с низким качеством. Для общей аналитики это не мешало; если упрёмся — отдельный трек с командой Voice по качеству транскрибации. Прецедент есть: прошлая команда Кости ходила к ним с тем же и пробовала whisper вместо SaluteSpeech, Кошевой недавно приходил с whisper в ПРОМ. Костя уточнит у коллег, где это сейчас
Что остаётся неудобным: на ИФТ текста в логах нет, тесты новых промптов разбираем по своим заметкам или включаем запись для проекта
✅Что уже известнообновлено 08.09
ПРОМ: учётка Kibana получена 07.09 письмом от команды мониторинга SberDevices — elk-alpha-prod, роль support_3line, вход на kibana.sdmon.omega.sbrf.ru из домена OMEGA. Отдельного тикета не потребовалось, форма ДРУГ на АС SmartNLP.Мониторинг (ПРОМ) и была маршрутом. Транспортный пароль сменить при первом входе
ПРОМ: учётка PVS получена 08.09 вторым письмом от Челышева — pvs-alpha-prod, роль support_3line, https://pvs.sdmon.omega.sbrf.ru. Это отдельная система со своей учёткой: форма ДРУГ её не даёт, команда мониторинга выдаёт по отдельному письму. Транспортный пароль тоже сменить
ИФТ: учётка Kibana получена 08.09 в 17:58 — «ELK Sigma: Dev, IFT, NT, Demo», роль support_3line, https://kibana.ift.sdmon.delta.sbrf.ru. Тикет SDMON-5197 закрыли за два с половиной часа, маршрут подтверждён второй раз. Транспортный пароль сменить. Название учётки «Sigma» историческое: ИФТ-контур ELK давно на Delta
ИФТ: PVS — https://pvs.ift.sdmon.delta.sbrf.ru, вход под общим просмотровым логином Viewer, он в закрепе чата «Салют в IVR КИБ» (значение здесь не публикуем). Закреп январский: адрес и логин актуальны, а индекс-паттерн в ссылке (filebeat-b2b-skillflow-ivr-ci08270137-ift) — до переезда индексов 24.08, актуальные — s.kib-ckr-text-va.smnlp-sf-ivr.*. По адресу видно, что PVS — это OpenSearch Dashboards: тот же Discover и index pattern, что в Kibana
⚠️ На ИФТ текста диалога в логах нет. Kibana и PVS на ИФТ показывают только обмен SkillFlow ↔ SmartIVR: факт звонка, сценарий, время, session-id и то, что SkillFlow передал в IVR — в том числе промпт целиком. Реплики генерирует GigaVoice, и они ходят между SmartIVR и GigaVoice, минуя SkillFlow. Текст в этих логах был бы только у линейного сценария, где реплики лежат в самом SkillFlow
Текст на ИФТ виден только в отладке SmartIVR, и только онлайн — во время звонка. Доступа к ней нет, и для разбора постфактум она бесполезна
Полная картина есть на ПРОМ. PVS IVR на ПРОМ (контур Омега) показывает весь текст диалога, тексты, ушедшие в TTS, чем завершилась сессия и call trace. Это самый информативный инструмент из имеющихся. Доступ отдельный, под свою учётку, через ДРУГ. Диалоги волны 28.08 присылали именно оттуда
Voice360 — доступ есть. Витрина, куда с ПРОМ попадает весь диалог с кодом завершения, там же запись. Для разбора реальных обзвонов это основной инструмент; на ИФТ его нет
Это не отдельная учётка GigaChat, а доступ к общей платформе логирования Elastic, где лежат индексы SmartNLP и GigaChat. Работа идёт через интерфейс Kibana
Поиск по request-id там работает — проверено на запросе к GigaChat из ноутбука на ИФТ. ⚠️ На звонке это не проверялось: что можно найти запрос, порождённый звонком, — открытый вопрос
Маршрут заявки быстрый: тикет SDMON-5160 «Доступ к кибане IFT» заведён и закрыт за 13 минут, учётные данные и ссылка пришли письмом
ПРОМ — отдельная заявка по другому маршруту, подана 02.09, учётка пришла 07.09. Учётка нужна каждому своя
🧭Контурычто где тестируется
У SmartIVR три контура: ИФТ, ПРЕДПРОМ, ПРОМ. У SkillFlow только два: ИФТ и ПРОМ
ПРЕДПРОМ по IVR идентичен ПРОМ, но сценарий SkillFlow там уже боевой: звонок на ПРЕДПРОМ идёт по промовскому промпту и по клиентам
Быстро менять и тестировать мы можем только на ИФТ: изменения сценария и промпта на ПРОМ вносит команда сценариев
На ИФТ логи без текста, на ПРОМ — с текстом. Поэтому разбор реплик — по ПРОМ, а проверка механики сценария и переданного промпта — по ИФТ
🗺Что где лежит — предположительносверить с Качаловой под запись
ИФТ · Kibana — kibana.ift.sdmon.delta.sbrf.ru, учётка «ELK Sigma: Dev, IFT, NT, Demo». Лежит: обмен SkillFlow ↔ SmartIVR — факт звонка, сценарий, время, session-id, что SkillFlow передал в IVR, включая промпт целиком; отдельно индексы SmartNLP и GigaChat, где по request-id находится запрос к модели (проверено на запросе из ноутбука, не на звонке). Индексы SkillFlow: s.kib-ckr-text-va.smnlp-sf-ivr.{ingress,egress,contman,smapp}.*. Искать: Discover, data view s.*, фильтр context.user_id: <номер>; поля session-id, request-id; сменить диапазон дат. Нет: текста реплик, текстов TTS, call trace
ИФТ · PVS — pvs.ift.sdmon.delta.sbrf.ru, общий просмотровый логин из закрепа чата «Салют в IVR КИБ». Паттерны в январских ссылках закрепа (filebeat-b2b-skillflow-ivr-ci08270137-ift, s.salut-ivr.skillflow.b2b.ift) устарели после переезда 24.08 — в PVS выбирать актуальные s.kib-ckr-text-va.smnlp-sf-ivr.*, если они там есть. Лежит то же, что в Kibana ИФТ, но по сессиям: запросы в формате вопрос-ответ, длительности. По словам Кати, нужен только для багов в связке SkillFlow ↔ IVR
ПРОМ · Kibana — kibana.sdmon.omega.sbrf.ru, учётка elk-alpha-prod. Лежит: индексы «чисто IVR-овские» — сервисы сессии (завершение или незавершение), tts collector с текстами на озвучку, call trace, business details. Имена индексов, поле для фильтра по нашему сценарию и есть ли на ПРОМ индексы SkillFlow — неизвестно. Рядом kibana-report.sdmon.omega.sbrf.ru для выгрузки CSV
ПРОМ · PVS — pvs.sdmon.omega.sbrf.ru, учётка pvs-alpha-prod. Лежит: весь текст диалога, тексты в TTS, завершение сессии, call trace (disconnect — IVR, far — клиент, transfer — перевод), шаги по дереву, UUID взаимодействия для SCPL, вся информация по session id. Как найти звонок — по номеру, по дате или только по session id — уточнить
Вопросы Кате под запись: 1) имена индексов IVR на ПРОМ и поле, по которому отфильтровать наш сценарий SALUT_agent_sales_outbound; 2) есть ли на ПРОМ индексы SkillFlow и промпт в них; 3) как в PVS ПРОМ найти звонок по номеру и дате; 4) где в PVS UUID и call trace, видны ли тайминги между репликами; 5) в каком событии виден переданный в IVR код завершения; 6) в каком поле в Kibana ИФТ лежит переданный промпт; 7) какой индекс-паттерн выбирать в PVS ИФТ после переезда 24.08 — январские из закрепа устарели; 8) наш greenfield — gf, gf2 или main; 9) включена ли запись SCPL для проекта на ИФТ
🔐Доступ на ИФТучётка Kibana получена 08.09
✅ Тикет SDMON-5197 «Доступ к Kibana ИФТ» заведён 08.09 в 15:30, учётка пришла письмом в 17:58. Исполнителя назначать не нужно: по инструкции достаточно комментария-согласования от Еременко, Соловьёва или Романенкова, после этого команда мониторинга берёт тикет сама и присылает письмо с данными для входа
Инструкция: Confluence, пространство «Мониторинг SberDevices», страница «Доступы», pageId=9409597821, раздел «Grafana & Kibana & PVS (ИФТ, Дев, НТ)»
Шаг 1. Заявка в ДРУГ «Доступ к стендам разработки и тестирования», в поле автоматизированной системы указать SmartNLP (CI01808661). Сегмент сети — ваш фактический, обычно SIGMA
Шаг 2. После согласования — тикет в бэклог Jira, проект SDMON (SberDevices Monitoring), свободная форма. Готовый текст:
Доступ к Kibana ИФТ
Прошу предоставить read-only доступ к Elastic/Kibana ИФТ для поиска логов
SmartNLP и GigaChat по request-id в рамках диагностики проекта ЦКМ.
Сетевой доступ к SmartNLP (CI01808661) получен по заявке SD0289350910.
Сегмент: SIGMA, физдоступ имеется.
Согласуйте, пожалуйста, Еременко Руслан Александрович,
Романенков Максим Владимирович.
Шаг 3. В комментарии к тикету нужно согласование от Еременко Руслана, Соловьёва Дмитрия или Романенкова Максима; назначать исполнителя самому не нужно. Учётка приходит письмом со ссылкой на ресурс. Такой тикет закрывали за 13 минут
💡 Просить узко. PVS и Grafana в тикете не перечислять — проверенная формулировка упоминает только Kibana. Если чего-то не окажется, второй тикет займёт столько же времени, а широкая заявка может уйти на лишние согласования
Оговорка «Kibana — параллельно предоставляется доступ к PVS» относится к форме ДРУГ на ПРОМ и ПСИ, а не к свободному тикету на ИФТ
🏭Заявка на ПРОМKibana 07.09, PVS 08.09 — доступ есть
✅ Kibana: учётка получена 07.09 письмом «Мониторинг SberDevices: доступ»: elk-alpha-prod, роль support_3line, https://kibana.sdmon.omega.sbrf.ru. Отдельного тикета не потребовалось
✅ PVS: учётка получена 08.09 отдельным письмом «Предоставление доступа» от Челышева: pvs-alpha-prod, роль support_3line, https://pvs.sdmon.omega.sbrf.ru. Форма ДРУГ PVS не даёт — его надо попросить у команды мониторинга письмом, и они высылают. Для коллег: сразу просить обе учётки
Транспортные пароли из обоих писем сменить при первом входе, вход из домена OMEGA
⚠️ ИФТ этих звонков не покажет. Внутренняя волна 28.08 проходила на ПРОМ, и штатные записи есть только на ПРОМ
Что там смотреть — PVS IVR в контуре Омега. Индексы на ПРОМ другие, чисто IVR-овские: сервисы сессии, tts collector с текстами на озвучку, call trace с завершением. По session id видна вся информация по звонку, по шагам — куда вошли и чем закончилось
Завершение в call trace: disconnect — трубку положил IVR, то есть мы сами; far — положил клиент; transfer — IVR перевёл звонок
Учётка PVS на ПРОМ — своя, под контур Омега; общий просмотровый логин ИФТ туда не подходит. Форма ДРУГ её не даёт, несмотря на оговорку «параллельно предоставляется доступ к PVS»: выдали по отдельному письму команде мониторинга
Маршрут другой: ДРУГ, услуга «Доступ к автоматизированным системам Банка» — не «к тестовым ресурсам»
Тип заявки — Открытие. Класс среды — Промышленная. В этом положении стенд ПСИ для выбора недоступен, но он сейчас и не нужен
Автоматизированная система — АС SmartNLP.Мониторинг (ПРОМ)
⚠️ Форма даёт одну комбинацию, а не набор галочек. Как только отмечаешь Kibana в «Области данных», Grafana из выбора пропадает — то же с доменом. Grafana, если понадобится, подаётся отдельной заявкой с ролью «Пользователь viewer Grafana». Для поиска логов она не нужна
Полномочия — выпадающий список: Администратор Grafana, Пользователь 1line, Пользователь 3line, Пользователь smartapp_ide, Пользователь smsaide_rt_3line, Пользователь viewer Grafana. Выбран Пользователь 3line: 1line — первичный операционный мониторинг, 3line — техническое расследование. Выбор приняли: в письме выдана роль support_3line
Область данных Виртуального Ассистента — B2B
Домен — тот, с которого работаете. С рабочего места на ПРОМ это OMEGA
Обоснование заполняется без указания полномочий, например: «Для доступа к логам запросов GigaChat по проекту ЦКМ (цифровой клиентский менеджер)»
🧩Что есть чточтобы не путать инструменты
Elasticsearch — база, где физически лежат логи и по которой идёт поиск. Учётку называют «учёткой Elastic», потому что заводится она именно там
Kibana — интерфейс к Elasticsearch. Открываете Discover, выбираете индекс, находите событие по полю и смотрите его целиком — запрос показывается весь, большой и длинный
PVS — просмотрщик того же класса (по адресу — OpenSearch Dashboards), с разбивкой по сессии: запросы по звонку в формате вопрос-ответ, длительность каждого запроса, ответ агента. Для разбора звонков удобнее Kibana. На ИФТ и ПРОМ это разные инсталляции с разными входами: ИФТ — https://pvs.ift.sdmon.delta.sbrf.ru под общим логином, ПРОМ — https://pvs.sdmon.omega.sbrf.ru под своей учёткой
Отладка SmartIVR — живой лог обмена IVR со всеми интеграциями, включая тексты на TTS. Работает только онлайн, прошлые звонки не показывает. Не наш инструмент
Voice360 — витрина, куда с ПРОМ попадает весь диалог с кодом завершения; там же можно послушать запись. По содержанию близко к PVS IVR ПРОМ, но без call trace и таймингов. Доступ есть
Витрины СМД — для заказчиков: тексты диалогов в чистом виде. Команда сценариев ими не пользуется
SCPL — система записи, где лежат аудиозаписи звонков: поиск по UUID взаимодействия, прослушивание. Для ИФТ и ПРОМ отдельные. Название подтверждено командой GigaVoice
Стенд TTS — отдельный стенд GigaVoice для проверки синтеза: вводишь текст, слушаешь, заводишь дефект
Grafana — графики и мониторинг: версии сервисов, доступность, ошибки, задержки во времени. Для разбора звонков не используется — ни нами, ни командой сценариев
Разница на практике: в Kibana ищете конкретное событие — «запрос с таким request-id в 14:32 и что в нём было». В Grafana смотрите общую картину — «сколько сегодня ошибок и какая версия сервиса работает»
🔎Что проверить самому на ИФТдоступ есть
Найти тестовый звонок 07.09 по номеру и времени — в PVS и в Kibana. Убедиться, что видны сценарий, session-id и переданные в IVR данные
Промпт: посмотреть, что именно SkillFlow передал в IVR — он там целиком. Сверить с нашим текстом: не дописано ли что-то сверху и не задвоился ли он
Какие индексы и data view открылись: только SkillFlow и IVR — или ещё GigaChat и GigaVoice
Имена полей известны из документации:X-Session-ID и X-Request-ID пишутся в каждое сообщение лога как session-id и request-id. Искать по ним
Латенси искать как отдельные записи: поле metric_name со значениями asr_latency, gopro_latency, tts_latency, turn_taking_latency, рядом process_time в миллисекундах и request_id_n
Есть ли событие service_info с версией движка
Находятся ли логи SkillFlow по context.user_id на индексах Delta
⏰ Не забыть сменить диапазон с Last 24 hours на дату звонка
Чего на ИФТ искать не нужно: текста реплик и тела запроса в GigaChat со стороны звонка — обмен IVR ↔ GigaVoice в Kibana не пишется
Главное: взять эталонный звонок и попробовать дойти от него до запроса в GigaChat. Это и есть незакрытый участок цепочки — и на ИФТ он, похоже, не закрывается
🗂PVS и индексы SkillFlow
Старый индекс s.salut-ivr.skillflow.b2b.ift* после 24.08 пустой
Причина переезда: ИФТ-контур ELK на Sigma выведен из эксплуатации, всё переехало на Delta. Новые индексы и алиасы там создаются автоматически в течение часа после начала поступления данных
Рабочий приём: широкая выборка s.* с фильтром context.user_id: <номер> — отдаёт входящие и исходящие события Kafka по звонку
ИФТ, Delta: https://kibana.ift.sdmon.delta.sbrf.ru, обращение к elasticsearch по API https://api.elk.ift.sdmon.delta.sbrf.ru
ПРОМ, Alpha: https://kibana.sdmon.omega.sbrf.ru, отдельная Kibana для выгрузки csv-отчётов https://kibana-report.sdmon.omega.sbrf.ru, API https://api.elk.sdmon.omega.sbrf.ru
➕ Эти индексы относятся к SkillFlow и IVR: ingress, egress, context manager, application logs. Их наличие не означает, что там же лежат полные логи GigaVoice или тело запроса GigaChat
➕ На ПРОМ индексы совсем другие — IVR-овские. Смотреть там сервисы сессии, tts collector и call trace, а не SkillFlow
➕ В закрепе чата «Салют в IVR КИБ» ссылка на PVS ИФТ январская, с паттерном filebeat-b2b-skillflow-ivr-ci08270137-ift — он до переезда 24.08. Адрес и логин из закрепа рабочие, паттерн в PVS выбирать актуальный; какой именно — уточнить у Качаловой
📦Собрать эталонный звонокдоступы не нужны
Взять звонок 16 из обзвона 28.08 — внутренняя волна, не клиенты, есть расшифровка и разбор
Зафиксировать в одном файле: дату и время, номер, расшифровку, наблюдаемое поведение, completion code
Это не проход цепочки, а заготовка. Прикладывать к каждому обращению ниже
Voice-дефекты рассматриваются по конкретным кейсам с session id и аудио, поэтому эталонный звонок существенно упростит обращение
У одного человека — не у всех сразу — попросить разовую выгрузку по этому звонку
📊СМД и Voice360для логов не нужен
✅ Решено 08.09: для разбора звонков хватает Voice360 и PVS IVR ПРОМ. Подписку на витрину как источник логов не заказываем
Витрины СМД — инструмент заказчиков: тексты в чистом виде. Voice360 — тоже витрина, но с диалогом, кодом и записью; данные туда попадают с ПРОМ
Витрины с данными клиентов (ПКАП ММБ, уровни доверия, история взаимодействия) — дорожка Кости для персонализации, к логам не относится
Ниже — на случай, если массовая регулярная выгрузка всё же понадобится; спрашивать у Яшагина и Паничева:
Точное название или ID подписки со звонками ЦКМ
Точное значение source для фильтра
Точное имя поля с идентификатором записи и как по нему слушать через PVS
➕ PVS — интерфейс просмотра и поиска, СМД — источник и подписка на данные. Доступ к PVS не заменяет подписку и право выгрузки
Read-only доступ с правом выгрузки + retention
Разовая выгрузка эталонного звонка со всеми полями
Какие correlation-поля есть: call_id, voice_call_ID / session_id, id записи, возможно request_id / turn_id
⚠️ RqUID GigaChat в витрине отсутствует — запросы идут внутри платформы SmartIVR. Не закладываться
Подписка оформляется через Лабораторию данных
🎧АудиоSCPL · слушать можно, скачать — нет
Записи лежат в SCPL, отдельно для ИФТ и ПРОМ. Доступ — через ДРУГ
Как найти запись на ПРОМ: в PVS IVR найти диалог и взять его UUID, в SCPL открыть «Взаимодействия» → поиск, ввести UUID — и слушать
На ИФТ сначала проверить, включена ли запись для нашего проекта. Запись не автоматическая, её включают отдельно. Если включена — искать по проекту и времени звонка
⚠️ Скачать файл штатно нельзя — по крайней мере, никто этого не делал: когда нужна запись, её пишут с экрана или на диктофон
⚠️ Двух дорожек нет. Запись одна, смешанная. Команде GigaVoice для кейса из сессии нужно слышать и пользователя, и бота: ЦКР для этого пишут аудиокейс встроенным диктофоном с SCPL — как именно, спросить у Кулагина или Колокольникова. Для дефектов на конкретной фразе аудио не нужно: стенд TTS
На ПРОМ послушать запись можно и из Voice360
🎛Стенд TTS — дефекты синтезадва маршрута, по Головину
Стенд: https://webfront-dev.cloud.delta.sbrf.ru/tts/. Вводишь текст, выбираешь голос и качество, запускаешь синтез, слушаешь. Если озвучено плохо — прямо оттуда заводится баг на команду GigaVoice
Маршрут 1 — ошибка воспроизводится на стенде: завести баг на стенде и сразу скинуть ссылку в чат GigaVoice. Формы не нужно
Маршрут 2 — ошибка в сессии GigaVoice: заполнить форму с указанием контура (ПРОМ или ИФТ), greenfield (gf, gf2, main) и session_id. Стенд здесь не замена: команде нужно слышать и пользователя, и GigaVoice, и смотреть другие аномалии сессии, которые могли повлиять на кейс. Прогон фразы на стенде — дополнение «для уверенности», не вместо формы
Аудио для формы: ЦКР пишут аудиокейс через встроенный диктофон — аудио с SCPL. Как именно — спросить у Егора Кулагина или Алексея Колокольникова
Открытый вопрос: на каком greenfield идут наши сессии — gf, gf2 или main. Уточнить у Качаловой, без этого форму не заполнить
Качество ставить 8000 — телефония больше не пропускает, это ограничение платформы. Между 8 и 48 кГц разница огромная, но 48 нам недоступно
Голосов там много — все, что есть у движка. Наш выбирать по названию (в разговоре звучало «lifelike» — уточнить)
Прогонять фразу 2–3 раза: синтез меняется от запуска к запуску, дефект может проявиться не с первого раза
Для «интонация не та» на конкретной фразе это самый дешёвый путь: воспроизвести на стенде на нашем и ещё двух голосах и завести баг. Если на стенде не воспроизводится — это уже кейс сессии, маршрут 2
Доступ оформлять не нужно: стенд открывается из офисной сети без заявок, там же можно послушать все голоса Сбера. С удалёнки не открывается, в том числе через Омегу — проверено 08.09 несколькими коллегами. На этом же стенде новые релизы TTS тестируют до выкатки
🧾Логи GigaVoiceне проверено
По voice_call_ID в Kibana находятся все логи GigaVoice — так сказали владельцы движка. Своей проверки не было
⚠️ В Kibana ИФТ обмена IVR ↔ GigaVoice нет — там только SkillFlow ↔ IVR. Тексты, ушедшие в TTS, видны в отладке IVR (онлайн) и в PVS IVR на ПРОМ (tts collector)
Отдельной системы для этого нет: доступ тот же, что к Kibana выше. Названия «АС NLP_Кибана» в инструкции по доступам не существует — это было распознано со слуха
Состав trace, который нужен: ASR, запрос в GigaChat с system prompt и messages, ответ, function call и результат, текст в TTS, ошибки, latency, VAD и перебивания, completion
🔗 X-Session-ID = voice_call_id — по документации это тождество, маппинг на уровне сессии не нужен
⚠️ X-Request-ID генерирует сам GigaVoice на каждую реплику. Логи GigaChat ищутся по request-id — совпадают ли эти значения, не проверено. Это главный открытый вопрос
Чанки одного синтеза несут общий uuid с суффиксами _m, _n. Одна реплика ≠ одна строка
🚫 Доступ в среду разработки SmartIVR не запрашивать — это инструмент разработчиков, не пользовательский маршрут
🔑Пермишены GigaVoiceне запрашиваем
✅ Решено 08.09: не запрашиваем. Жалобы последнего времени только на интонацию синтеза, а её разбираем на стенде TTS. Ниже — справка на случай, если задержки снова станут темой
⚠️ Просить преждевременно. Раздел документации называется «Логирование латенси и метрик»: компонентные латенси пишутся в серверные логи GigaVoice отдельными записями. Если Kibana отдаст индексы GigaVoice, метрики там уже будут и пермишены не понадобятся
Эти два списка управляют отправкой событий клиенту — то есть SmartIVR, который их ещё должен сохранить. Для анализа это другой путь
Порядок: получить Kibana → найти звонок по session-id → проверить, есть ли записи с metric_name и событие service_info. Обращаться только если их не окажется
UserIDsWithServiceInfoAccess — версия движка в сессии
CN основного запроса: CI03219423-IFT-CORP и CI03219423-PROM-kiparis-ckr
Старый CI00747093-IFT-CORP добавлять только если подтвердят, что через него ещё идут вызовы — пермишены работают на будущие события и старых логов не откроют
Уточнить, куда мы складываем приходящие service_info и metric — пермишен открывает поток, интерфейса просмотра не создаёт
➕ Тем же сообщением: лежит ли для наших CN что-то в config.system_prompt? Промпт передаётся через SkillFlow, а по документации конфигурационный дописывается к переданному в любом случае — если там копия, склеятся две версии нашего же промпта
💰 Зачем они вообще нужны: без раскладки задержки по участкам претензию «долгие паузы» нечем подтвердить — не видно, где уходит время, на распознавании, генерации или синтезе
🎚️Dumper — не запрашиваемсправка
✅ Решено 08.09: не запрашиваем. Двухканальная запись нужна была под шаблон дефектов, а дефекты синтеза воспроизводятся на стенде без аудио из звонка
Документация подтверждает сохранение входящего клиентского аудио в S3. Сохранение отдельной дорожки синтеза не описано и не гарантировано
Может затронуть весь трафик соответствующего инстанса или контура — scope, хранение и допустимость подтвердить у владельцев
Команда сценариев про Dumper не слышала и им не пользуется — в PVS и Kibana его следов ждать не стоит
Формулировка: «можно ли использовать Dumper для CN ЦКМ, на каком контуре, куда попадает аудио, кто имеет доступ и решает ли это задачу двухканальной записи?»
ИФТ выглядит единственным разумным местом для эксперимента — но только после согласования
⏸ Спрашивать имеет смысл только если штатным способом нужное аудио получить не удастся
💻Рабочее место
Вслепую не заказывать. У владельца каждого инструмента спросить: Сигма, Альфа, Омега или отдельный ВАРМ
PVS ИФТ — общий просмотровый логин; PVS ПРОМ — своя учётка в контуре Омега
В форме ДРУГ на ПРОМ указываются логины сразу в двух доменах — OMEGA и SIGMA, и домен выбирается отдельным полем
Просмотр и выгрузка могут требовать разных контуров — уточнять оба отдельно
⏳ Не тот ВАРМ через ДРУГ — потеря недель
🔬После получения доступов — пройти цепочку самостоятельно
запись → UUID → диалог в PVS IVR ПРОМ → completion — этот участок на ПРОМ доступен штатно
voice_call_ID → trace GigaVoice → request-id → запрос и ответ GigaChat → TTS — этот участок по-прежнему не пройден
На том же эталонном звонке: мы знаем, что в нём было, поэтому сразу видно, чего в логах нет
Главный незакрытый участок — мост от звонка к request-id. Логи GigaChat уже доступны и ищутся по id; неизвестно, как получить этот id для конкретного звонка. На ИФТ его в Kibana нет: обмен IVR ↔ GigaVoice туда не пишется
Ключевое по промпту: сверить фактический контекст с тем, что отправил SkillFlow. Что отправил SkillFlow — видно в Kibana ИФТ целиком; что дошло до модели — пока не видно нигде. Собственного бизнес-промпта платформа не добавляет — проверяем, не задвоился ли наш промпт из конфига
При переданном silence_phrases_timeout в конец системного сообщения дописывается инструкция про пустое сообщение, а молчание пишется в историю как пара ходов, где ход клиента — пробел. Это одно из документированных платформенных дополнений к контексту: проверить, активна ли механика в нашем конфиге и нет ли других преобразований
⚠️Что не перепутать
СМД используется в проекте ещё и как источник исторических транскрибаций для персонализации. Это другая витрина и другая задача, технических логов не даст
Звонок на ПРЕДПРОМ для SkillFlow — боевой: промпт промовский, клиенты настоящие
Порядок
Разбор реальных обзвонов — через Voice360: текст, код завершения, запись. Уже работает
ИФТ — учётка Kibana получена 08.09, PVS открывается под общим логином из закрепа чата «Салют в IVR КИБ». Сменить транспортный пароль, найти тестовый звонок 07.09 в обоих, посмотреть, что SkillFlow передал в IVR и не задвоился ли промптсегодня
Сессия с Качаловой под запись: что и по каким индексам лежит в Kibana и PVS на ИФТ и ПРОМ, как найти звонок, где UUID и call trace, наш greenfield, включена ли запись на ИФТ — список вопросов в разделе «Что где лежит»сегодня
ПРОМ — учётки Kibana (07.09) и PVS (08.09) получены. Войти из OMEGA, сменить оба транспортных пароля. Дальше PVS IVR: звонки волны 28.08, кто положил трубку, тайминги, что ушло в TTS — и заодно проверить два непроверенных пункта из «Решения 08.09»сегодня
Стенд TTS webfront-dev.cloud.delta.sbrf.ru/tts/: открывается из офиса без заявок, с удалёнки нет. Дефект на фразе — воспроизвести на стенде на нашем и ещё двух голосах, баг на стенде плюс ссылка в чат. Дефект в сессии — форма с контуром, greenfield и session_id; спросить Качалову про наш greenfield, Кулагина или Колокольникова — как ЦКР пишут аудиокейс с SCPL
ИФТ: проверить, включена ли запись для нашего проекта, — иначе тесты на ИФТ не разобрать
Не запрашиваем: Grafana, СМД как источник логов, Elastic по API, Dumper, пермишены GigaVoice. Логи GigaChat отложены до ответа их команды по багу «функция без текста»
Витрины в Омеге и данные клиентов — Костя, отдельно от логов
Схема связей
Ключевое разделение. GigaVoice — оркестратор, а не модель. Неверная транскрибация — вопрос к ASR; верная транскрибация при кривом ответе — вопрос к GigaChat или к нашему промпту. Это позволяет делить дефекты по зонам ещё до обращения к смежникам. Второе разделение — по контурам: ИФТ показывает, что SkillFlow передал в IVR, но не реплики; текст диалога, завершение и ключ к записи есть только на ПРОМ. Дефекты синтеза воспроизводятся на стенде TTS, а не выкачиваются из звонка.
ASR, сборка контекста, запрос и ответ модели, function call, текст в TTS, ошибки, latency, VAD
Ключ
voice_call_ID
Внимание
В Kibana ИФТ обмена IVR ↔ GigaVoice нет
Статус
не проверено
Логи GigaChat
та же Kibana, ИФТ
Ключ
request-id
Доступ
Тикет SDMON-5160, закрыт за 13 минут
Проверено
Собственный запрос из ноутбука — не запрос от звонка
Решение
Отложено: по багу «функция без текста» команда GigaChat не отвечает, предъявлять логи некому
Статус
доступ есть · не используем
Пермишены GigaVoice
не запрашиваем
Даёт
service_info — версия движка в сессии metric — asr_latency, gopro_latency, tts_latency, turn_taking_latency
CN
CI03219423-IFT-CORP CI03219423-PROM-kiparis-ckr
Кто
Головин, Вяткин
Учесть
Латенси пишутся в серверные логи GigaVoice — если Kibana их отдаст, пермишены не нужны
Статус
не запрашиваем
подтверждено частично / требует проверки нужно запросить неизвестно
Что учесть
На ИФТ текста нет
Kibana и PVS ИФТ видят только обмен SkillFlow ↔ IVR. Реплики ходят между IVR и GigaVoice и на ИФТ видны только в отладке, онлайн. Voice360 тоже только про ПРОМ. Разбор реплик — по ПРОМ.
Сначала смотрим, потом спрашиваем
Почти всё, что хотелось уточнить у коллег, видно в логах самому. Обращение после проверки будет предметным: вот звонок, вот индекс, вот чего в нём нет.
ПРЕДПРОМ — это ПРОМ
У IVR три контура, у SkillFlow два. Звонок на ПРЕДПРОМ идёт по боевому сценарию SkillFlow. Менять и тестировать быстро можно только на ИФТ.
PVS — это не СМД
PVS — интерфейс просмотра и поиска, витрина СМД — источник и подписка для заказчиков. Voice360 — витрина с диалогом и записью, данные туда попадают с ПРОМ.
ИФТ и ПРОМ просят по-разному
На ИФТ — свободный тикет, и формулировка узкая: только Kibana. На ПРОМ — форма, и она открывает одну комбинацию: выбрали Kibana — Grafana пропала из списка. Grafana при необходимости подаётся отдельно. Учётки PVS на ИФТ и ПРОМ тоже разные.
Одна дорожка
Запись звонка одна, смешанная; скачать её штатно нельзя. Дефект на фразе — стенд TTS. Кейс из сессии — форма и аудиокейс с SCPL, как это делают в ЦКР: спросить Кулагина или Колокольникова.
Dumper — не решение для аудио
Только входящий клиентский звук; дорожка синтеза не гарантирована. Может затронуть весь трафик инстанса. Команда сценариев им не пользуется. Уместен, похоже, только на ИФТ и только после согласования.
Две разные витрины СМД
Нужна витрина с результатами звонков. Историческая витрина транскрибаций для персонализации — другая задача, технических логов не даст.
Кто за что отвечает
Кто
Зона
С чем идти
Екатерина Качалова
PVS ИФТ и ПРОМ, логи IVR, запись, Voice360, сценарий SkillFlow
Сессия под запись по индексам и поиску в Kibana и PVS на обоих контурах — вопросы в разделе «Что где лежит». Изменения сценария и промпта на ПРОМ идут через неё
Виктор Вяткин Павел Головин
GigaVoice · синтез, дефекты
Стенд TTS: баг на стенде плюс ссылка в чат, доступ не оформляется. Кейс из сессии: форма с контуром, greenfield, session_id и аудио. Порядок согласован с Головиным 08.09
Егор Кулагин Алексей Колокольников
ЦКР · аудиокейсы для GigaVoice
Как записывают аудиокейс встроенным диктофоном с SCPL, чтобы было слышно и клиента, и бота
Павел Головин Виктор Вяткин
GigaVoice
Пермишены service_info и metric по CN; вопросы по Dumper; лежит ли что-то в config.system_prompt для наших CN
Николай Яшагин Сергей Паничев
СМД, SmartIVR, аудиозаписи
Название и ID подписки, точный source, поле с идентификатором записи, retention, право выгрузки, разовая выгрузка эталонного звонка
SberDevices Monitoring
Kibana, PVS, Grafana
Заявка в ДРУГ на SmartNLP (CI01808661), затем тикет в бэклог Jira SDMON в свободной форме. Согласующие — Еременко Руслан, Соловьёв Дмитрий или Романенков Максим; исполняет и присылает учётки Челышев Алексей. PVS ПРОМ выдаётся отдельной учёткой по письму ему
Дарья Толстова
GigaChat
Баг «вызов функции без возврата текста»: логи отправлены, после первых ответов реакции нет. Пока обходим в промпте
Константин Медведев
Витрины в Омеге, данные клиентов
ПКАП ММБ, уровни доверия, история взаимодействия — для персонализации и оцифровки эффективности. Проходит доступы первым, потом расскажет