Логи и доступы ЦКМ

Что запрашивать, у кого и в каком порядке, чтобы получить возможность выгружать диалоги, аудиозаписи и технические логи звонков. Состояние на 09.09: доступы к Kibana и PVS на обоих контурах получены, сессия с Качаловой прошла — индексы, поиск, SCPL и стенд TTS показаны на живых звонках. Открытых вопроса три: пускает ли наша учётка в IVR-овский PVS на ПРОМ, работает ли мост от звонка к запросу в GigaChat через логи GigaVoice и где на ИФТ читаемый текст реплик. Сверху — инструкция целиком, ниже — схема связей и пояснения к ней.

Инструкция

🎯Цель

Регулярно выгружать диалоги и записи для разбора звонков
По конкретному дефекту доходить до «что реально ушло в модель»

🎬Сессия с Качаловой 09.09 — что показанопо записи и 23 скриншотам

Kibana ИФТ. Индекс filebeat-nlp-dialog-policy-b2b-ift-7.x — «старый», но живой: тестовый звонок 07.09 нашёлся. Поиск — просто номер телефона в строке поиска, отдельного поля больше нет, совпадение подсвечивается (в Kibana номер сессии равен номеру телефона, поэтому находится всегда). Фильтры args.channel: CCIVR_B2B, args.incoming_text: exists; колонки args.incoming_text, args.outgoing_pronounce_text, args.intent, message. Строки — пары «Incoming MESSAGE_FROM_USER» / «Outgoing to topic: vps», args.intent — SALUT_agent_sales_outbound. Появляется почти в реальном времени
Что внутри на ИФТ: только обмен SmartNLP (SkillFlow) ↔ IVR — во что положили промпт, под каким именем улетело, название сценария и интента, session-id. Промпт лежит целиком. Реплик нет, потому что текст ходит между IVR и GigaVoice мимо SkillFlow. Кате это нужно для отладки «кубиков» SkillFlow, нам — чтобы проверить переданный промпт
PVS ИФТ (pvs.ift.sdmon.delta.sbrf.ru): четыре паттерна s.kib-ckr-text-va.smnlp-sf-ivr.{ingress,egress,contman,smapp}.*. Полезен только smapp: по номеру телефона в поиске (фильтр message: exists) нашлись те же 4 события 07.09 — KAFKA Outgoing ANSWER_TO_USER и KAFKA Incoming MESSAGE_TO_SKILL, в args.message полный JSON: uuid.userChannel, payload.intent, pronounceText, smart_app_data с нашим промптом и functions (dialog_end с описанием), app_info.systemName: smartapp_skillflow_ivr_b2b, projectId, applicationId. Номер лежит только в args, в других паттернах его нет
ingress, egress, contman — инфраструктурный шум: xdsproxy connected to delta upstream XDS server, сертификаты, Ceph state for intent gigavoice, bpm content. По номеру там ничего не найти. Старый паттерн s.salut-ivr… «сдох», данные в новых с 31.08
Вывод по ИФТ: Kibana удобнее PVS — реальное время, одна таблица, поиск по номеру. PVS должен был показывать обмен NLP ↔ агент, но с GigaVoice текста там нет. По словам Кати, обмен IVR ↔ GigaVoice логируется «в прокси» на стороне GigaVoice и GigaChat — туда у неё доступа нет. Коды завершения на ИФТ в логах SkillFlow не видны: они идут из GigaVoice в IVR напрямую, в SkillFlow оказались бы только у ветвистого сценария
PVS IVR ПРОМ — это другой PVS. Катя показывала smartivr-pvs.omega.sbrf.ru/pvs/ из VARM Standart Alpha; это PVS команды SmartIVR, не pvs.sdmon.omega.sbrf.ru из письма мониторинга. Паттерны divrstat-ckr-*, данные с 31.08, звонки волны 28.08 там есть. Подходит ли наша учётка pvs-alpha-prod к этому адресу — проверить первым делом; если нет — спросить Катю, как оформлен её доступ. На ИФТ этот PVS тоже есть, но ссылка у Кати битая, ждёт от коллеги из команды IVR
divrstat-ckr-business_value* — главный. Поиск по названию сценария SALUT_agent_sales_outbound в строке поиска даёт все наши звонки, дальше выбирать по времени; по sessionId в кавычках — один звонок. Фильтр statData.bvs.secion: is one of callTrace, reviseContexStore, Appeals, ivrSteps, OutboundContCommObj, reviseSingleNum, recallDepartment, revisePOM; колонки statData.bvs.sense, statData.bvs.secion, sessionId. Один звонок раскладывается на несколько записей по бизнес-логикам
revisePOM — выжимка диалога: сценарий, весь диалог по ролям ivr: / client:, темы, «Результат звонка» (IVR_callback60 в примере), оценки, код для МИО. «Если нужен текст — бери revisePOM». ivrSteps — шаги в IVR (ENTER_agent_sales_dnis_…, EXIT_END_CALL) и eduid — ключ к SCPL. OutboundContCommObj — JSON исхода: callerNumber, source, robotofob, eduid, sfIId, duration, epkId, theme, callResult: CALL_FINISHED, phrases[] с dateTime, stepName, userType ROBOT, текстом каждой реплики — тайминги реплик берутся отсюда. reviseContexStore — ответ от CS: статусы аутентификации, orgRepresentative, ucpIds, inn, UCID, приоритет звонка
divrstat-ckr-services* — системные логи: sessionId, statData.requestBody, responseBody, short_url, method, responseCode, responseDuration. В каком сервисе что получили и что отправили; например, регистрация исхода в МИО — commhub-api/…/communication/create с commResultDetailCode. Сюда идти за «почему подставилась не та информация»
divrstat-ckr-session* — кто завершил: statData.end_details = near end disconnect (логика сценария дошла и закрылась сама), far (клиент бросил трубку), transfer (перевели по сценарию); рядом end_type, duration_ms, eduid, ivr_name, primary_ani, primary_dnis, ucid
divrstat-ckr-tts-collect* — фразы, ушедшие на озвучку: statData.node_id: GV (реплики GigaVoice), statData.value с текстом, mrcpSessionIdTts, ttsServer, visitId. Метки времени у всех фраз одного звонка одинаковые — записываются пакетом в конце, для пауз не годятся. SSML-теги, если мы их передадим, будут видны здесь же
Kibana Омега Катя не открывает: «всё есть в PVS», идти туда только при подозрении, что отправленное в NLP отличается от прилетевшего, — а оно не отличается
SCPL ПРОМ (b2b.scpl.omega.sbrf.ru, VARM Alpha): «Детальная статистика» → «Статистика по взаимодействиям» → «По взаимодействиям». Поиск по «ID взаимодействий» = eduid из PVS. Показывает родительское взаимодействие и сегменты: сегмент с нашим сценарием «ИСХОД-ПРОД. Agent_Sales…» имеет значок записи, его ID совпадает с sessionId из PVS. Нажать «слушать» — и всё. Поиск по номеру: обязательно дата в «Периоде взаимодействий» (иначе «захлебнётся»), в «Телефоны клиента» — звёздочка и номер без 8 или +7; выдаёт все звонки за день с типом сценария, направлением и признаком оператора
Диктофон. Скачать запись из SCPL нельзя, Катя пишет на диктофон. «Встроенный диктофон ЦКР» из чата GigaVoice, похоже, обычный диктофон — Кулагина и Колокольникова спрашивать не обязательно
Стенд TTS. Вкладки TTS UI, ASR UI, Metrics, ASR Bugs, TTS Bugs. Стенд IFT_GIGA_TTS_v100, синтез по grpcs://nlb-nlbagent-ttsapi-ift.delta.sbrf.ru:9010. SSML-кнопки: speak, break_time, pitch, slope, loudness, speed, happy, sad, annoyed, whisper, audio. Ударение — апостроф перед ударной гласной: <speak>де'позита</speak> произносится правильно всегда; эмоция — <voice mode="happy">…</voice>; пауза — break_time в миллисекундах, Катя держит 2000 в детерминированном сценарии. Галочка SSML и Validate, качество 8000
Теги IVR не вырезает и передаёт в TTS, поэтому в теории работают и из текста модели — но это «по идее», проверить у Вяткина. Совет Кати: не играться — чем сложнее строка, тем больше шанс косяка; неверное ударение отдавать Вяткину в починку, апостроф — временная заплатка. Она тестирует такие кейсы сама и просит присылать интересные
Что прислал Вяткин через Катю (6 скриншотов «по связке GigaVoice и GigaChat», Kibana ИФТ): индекс filebeat-gigachat-gigavoice-gf-* ищется по session id и отдаёт trace GigaVoice — AUDIOSTREAM -> [synthesis_start], OutputProcessor … speaking_main_answer, Started/Finished session with TTS backend, Metric WM-API latency, Metric Full TTS, TTS -> [session_finish]; индекс filebeat-gigachat-goprodigy* — шлюз к модели: поля request-id, session-id, alias-info.Name GigaChat-3-Pro, Model.Name GigaChat-3-120b-128k-base, user-agent, request.string с полными messages запроса; индекс filebeat-gigachat-wmcore-ift-7.x — ядро, по request_id три записи с model, functions, user_id. Катя: «тексты мы тут тоже не нашли» — по словам GigaVoice, они лежат в unicode-escape и их надо декодировать
Мост от звонка к запросу, гипотеза для проверки: session id голосовой сессии → filebeat-gigachat-gigavoice-gf-* → там же или в goprodigy по session-id найти request-id → request.string. Пример Вяткина был не от звонка (user-agent python-httpx), на нашем звонке цепочка не пройдена

🧭Решение 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 — после сессии 09.09 всё четыре пункта найдены в PVS IVR: кто завершил звонок — divrstat-ckr-session*, end_details = near end disconnect IVR, far клиент, transfer перевод; тексты, ушедшие в TTS, — divrstat-ckr-tts-collect*, реплики GigaVoice с пометкой GV (сырого ответа модели в логах IVR нет); тайминги реплик — phrases[].dateTime в OutboundContCommObj (business_value*), паузы считать по ним, расчёт не проверен; код завершения как переданное в IVR значение — «Результат звонка» в revisePOM и callResult с commResultDetailCode в регистрации исхода через services*
PVS и Kibana — два окна в одни данные. Логи лежат в Elasticsearch (ИФТ — Delta, ПРОМ — Омега). Kibana показывает сырые записи с временем и полями, PVS группирует их по сессии и показывает запросы и ответы, длительности, завершение и UUID. Смотреть через PVS, в Kibana ходить за точными метками и полями, которых PVS не показывает
Отдельная дорожка Кости — витрины в Омеге и данные клиентов (ПКАП ММБ, уровни доверия, история взаимодействия) для персонализации и оцифровки эффективности. К диагностике звонков не относится; он проходит доступы первым и расскажет
⚠️ Voice360 не идеален: часть диалогов не транскрибируется, часть — с низким качеством. Для общей аналитики это не мешало; если упрёмся — отдельный трек с командой Voice по качеству транскрибации. Прецедент есть: прошлая команда Кости ходила к ним с тем же и пробовала whisper вместо SaluteSpeech, Кошевой недавно приходил с whisper в ПРОМ. Костя уточнит у коллег, где это сейчас
Что остаётся неудобным: на ИФТ текста в логах нет, тесты новых промптов разбираем по своим заметкам или включаем запись для проекта

✅Что уже известнообновлено 09.09

09.09: индексы и поиск показаны Качаловой — раздел «Сессия с Качаловой» выше. Главные поправки: в Kibana ИФТ работает индекс filebeat-nlp-dialog-policy-b2b-ift-7.x, в PVS ИФТ полезен только …smapp.*; PVS IVR ПРОМ живёт на smartivr-pvs.omega.sbrf.ru, паттерны divrstat-ckr-*; ключ к записи в SCPL — eduid; логи GigaVoice на ИФТ есть в filebeat-gigachat-gigavoice-gf-*, полный запрос к модели — в filebeat-gigachat-goprodigy*, поле request.string
⚠️ Учётка pvs-alpha-prod выдана на pvs.sdmon.omega.sbrf.ru — PVS мониторинга SberDevices. IVR-овский PVS, который показывала Катя, — другой адрес и, вероятно, другой доступ. Проверить вход; если не пускает — узнать у Кати маршрут её доступа
ПРОМ: учётка 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 там уже боевой: звонок на ПРЕДПРОМ идёт по промовскому промпту и по клиентам
Быстро менять и тестировать мы можем только на ИФТ: изменения сценария и промпта на ПРОМ вносит команда сценариев
На ИФТ логи без текста, на ПРОМ — с текстом. Поэтому разбор реплик — по ПРОМ, а проверка механики сценария и переданного промпта — по ИФТ
Коды завершения на ИФТ в логах SkillFlow не видны: dialog_end уходит из GigaVoice в IVR напрямую. Единственный путь к тексту и кодам тестового звонка на ИФТ — логи GigaVoice и GigaChat в Kibana ИФТ, если мост от session id к request-id подтвердится

🗺Что где лежит — по сессии 09.09девять вопросов закрыты на семь

ИФТ · Kibana — kibana.ift.sdmon.delta.sbrf.ru. Индекс filebeat-nlp-dialog-policy-b2b-ift-7.x: обмен SkillFlow ↔ SmartIVR — факт звонка, сценарий и интент, время, session-id, промпт целиком. Искать номер телефона в строке поиска, фильтры args.channel: CCIVR_B2B и args.incoming_text: exists, диапазон дат сменить. Рядом индексы GigaVoice и GigaChat: filebeat-gigachat-gigavoice-gf-* по session id, filebeat-gigachat-goprodigy* по request-id и session-id, filebeat-gigachat-wmcore-ift-7.x по request_id. Нет: реплик в читаемом виде, текстов TTS, call trace
ИФТ · PVS — pvs.ift.sdmon.delta.sbrf.ru, общий просмотровый логин из закрепа. Паттерн s.kib-ckr-text-va.smnlp-sf-ivr.smapp.*, поиск по номеру с фильтром message: exists. Те же события, что в Kibana, но JSON целиком: промпт, functions, projectId, applicationId. Остальные три паттерна — шум. Нужен только для багов в связке SkillFlow ↔ IVR; для повседневного — Kibana
ПРОМ · PVS IVR — smartivr-pvs.omega.sbrf.ru/pvs/, VARM Alpha, доступ Кати. Паттерны divrstat-ckr-business_value* (диалог по ролям в revisePOM, «Результат звонка», шаги, eduid, OutboundContCommObj с таймингами реплик, данные клиента), divrstat-ckr-services* (запросы и ответы сервисов), divrstat-ckr-session* (кто завершил), divrstat-ckr-tts-collect* (фразы на озвучку). Искать по названию сценария, по sessionId в кавычках; по номеру — через SCPL с датой
ПРОМ · Kibana и PVS мониторинга — kibana.sdmon.omega.sbrf.ru, pvs.sdmon.omega.sbrf.ru, учётки elk-alpha-prod и pvs-alpha-prod. Что в них по нашему сценарию — не открывали: Катя Kibana Омега не использует. Предположительно там ПРОМ-аналог s.kib-ckr-text-va.smnlp-sf-ivr.* — проверить при первом входе
ПРОМ · SCPL — b2b.scpl.omega.sbrf.ru, VARM Alpha, через ДРУГ отдельно на ИФТ и Омегу. Поиск по «ID взаимодействий» = eduid или по дате плюс номер со звёздочкой; сегмент нашего сценария со значком записи, его ID = sessionId из PVS. Слушать можно, скачать нельзя
Ответы на девять вопросов: 1) индексы IVR ПРОМ — divrstat-ckr-*, сценарий ищется по имени SALUT_agent_sales_outbound в поиске ✔; 2) индексы SkillFlow на ПРОМ — не смотрели, открыто; 3) звонок по номеру и дате — в PVS по сценарию и sessionId, по номеру через SCPL ✔; 4) UUID и call trace — eduid в ivrSteps, завершение в session*, тайминги в phrases[].dateTime ✔; 5) код завершения — «Результат звонка» в revisePOM и callResult в OutboundContCommObj ✔; 6) промпт в Kibana ИФТ — в message события Outgoing, в PVS smapp — в args.message.payload ✔; 7) паттерн PVS ИФТ — …smapp.* ✔; 8) greenfield — не спрашивали, в примере Вяткина индекс gf, открыто; 9) запись SCPL на ИФТ — не спрашивали, открыто
Новые вопросы: пускает ли pvs-alpha-prod в smartivr-pvs.omega.sbrf.ru и как оформлен доступ Кати; ссылка на PVS IVR на ИФТ (Катя ждёт от коллеги из IVR); проходят ли SSML-теги из текста модели в TTS (Вяткин); где именно лежат unicode-тексты реплик в логах GigaVoice и как их декодировать (Вяткин)

🔐Доступ на ИФТучётка 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 смотрите общую картину — «сколько сегодня ошибок и какая версия сервиса работает»

🔎Что проверить самому на ИФТрецепт после сессии 09.09

Шаг 1, Kibana: индекс filebeat-nlp-dialog-policy-b2b-ift-7.x, номер телефона в поиске, фильтры args.channel: CCIVR_B2B и args.incoming_text: exists, диапазон на дату звонка. Взять session-id и событие Outgoing с промптом. Сверить промпт с нашим текстом: не дописано ли что-то сверху и не задвоился ли он
Шаг 2, PVS ИФТ: паттерн s.kib-ckr-text-va.smnlp-sf-ivr.smapp.*, номер в поиске, фильтр message: exists — тот же звонок в JSON целиком, с functions и projectId
Шаг 3, логи GigaVoice: индекс filebeat-gigachat-gigavoice-gf-*, в поиске session id в кавычках. Сначала — тот session-id, что из шага 1; если пусто — понять, какой id GigaVoice считает сессией. Смотреть msg: trace-события и строки Metric … — это те самые латенси, пермишены для них не нужны
Шаг 4, мост к модели: индекс filebeat-gigachat-goprodigy*, поиск по session-id того же звонка; если нашлось — забрать request-id и открыть request.string — там messages запроса целиком. Потом filebeat-gigachat-wmcore-ift-7.x по request_id. Тексты могут быть в unicode-escape — декодировать
Индекс gf — из примера Вяткина; если наши сессии на gf2 или main, паттерн другой. Это и ответит на вопрос про greenfield
Чего на ИФТ искать не нужно: реплик в логах SkillFlow и PVS — обмен IVR ↔ GigaVoice туда не пишется. Кодов завершения там тоже нет
Главное: пройти шаги 1–4 на одном тестовом звонке. Если шаг 4 сработает, мост от звонка к запросу закрыт и на ИФТ появляется полный текст

🗂PVS и индексы SkillFlowуточнено 09.09

Старый индекс s.salut-ivr.skillflow.b2b.ift* после 24.08 пустой. При этом в Kibana ИФТ индекс filebeat-nlp-dialog-policy-b2b-ift-7.x живой и показывает звонки 07.09 — им и пользуемся
Актуальные паттерны в PVS ИФТ (данные с 31.08):

s.kib-ckr-text-va.smnlp-sf-ivr.egress.*
s.kib-ckr-text-va.smnlp-sf-ivr.ingress.*
s.kib-ckr-text-va.smnlp-sf-ivr.contman.*
s.kib-ckr-text-va.smnlp-sf-ivr.smapp.*

➕ Полезен только smapp — события KAFKA Incoming MESSAGE_TO_SKILL и KAFKA Outgoing ANSWER_TO_USER с полным JSON. ingress, egress, contman — инфраструктура: xdsproxy, сертификаты, Ceph, bpm content
Причина переезда: ИФТ-контур 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 · показано 09.09

Записи лежат в SCPL, отдельно для ИФТ и ПРОМ. Доступ — через ДРУГ, заказывать оба контура. ПРОМ: b2b.scpl.omega.sbrf.ru, открывается из VARM Alpha
Как найти запись на ПРОМ: в PVS IVR (business_value*, записи ivrSteps или OutboundContCommObj) взять eduid; в SCPL «Детальная статистика» → «Статистика по взаимодействиям» → «По взаимодействиям», поле «ID взаимодействий», вставить eduid, «Показать». Раскрыть родительское взаимодействие: сегмент нашего сценария «ИСХОД-ПРОД. Agent_Sales…» со значком записи, его ID равен sessionId из PVS. Нажать «слушать»
По номеру: заполнить «Период взаимодействий» датой — без даты поиск «захлебнётся»; в «Телефоны клиента» ввести звёздочку и номер без 8 или +7. Выдаёт все звонки за день: сценарий, направление, был ли оператор; при переводе на оператора доступен его монитор, если есть права
На ИФТ сначала проверить, включена ли запись для нашего проекта. Запись не автоматическая, её включают отдельно. Если включена — искать по проекту и времени звонка
⚠️ Скачать файл штатно нельзя — Катя пишет на диктофон, никакого встроенного диктофона нет. «Встроенный диктофон ЦКР» из чата GigaVoice, видимо, тот же диктофон
⚠️ Двух дорожек нет. Запись одна, смешанная; в плеере клиент и бот различимы на слух. Для дефектов на конкретной фразе аудио не нужно: стенд 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. В примере Вяткина индекс логов gigavoice-gf-*; уточнить у него, без этого форму не заполнить
Качество ставить 8000 — телефония больше не пропускает, это ограничение платформы. Между 8 и 48 кГц разница огромная, но 48 нам недоступно
Голосов там много — все, что есть у движка. Наш выбирать по названию (в разговоре звучало «lifelike» — уточнить)
Прогонять фразу 2–3 раза: синтез меняется от запуска к запуску, дефект может проявиться не с первого раза
SSML, показано 09.09. Кнопки на стенде: speak, break_time, pitch, slope, loudness, speed, happy, sad, annoyed, whisper, audio. Ударение — апостроф перед ударной гласной внутри <speak>, работает всегда; эмоция — <voice mode="happy">; пауза — break_time в миллисекундах. Включить галочку SSML, кнопка Validate проверяет разметку. Стенд в списке — IFT_GIGA_TTS_v100, версия ядра видна там же
IVR теги не вырезает и передаёт в TTS вместе с текстом — в tts-collect на ПРОМ они были бы видны. Для текста, который генерирует модель, это «по идее должно работать» — подтвердить у Вяткина. Совет Кати: тегами не увлекаться, каждое усложнение строки повышает шанс дефекта; систематически неверное ударение отдавать Вяткину, апостроф — временная мера
Для «интонация не та» на конкретной фразе это самый дешёвый путь: воспроизвести на стенде на нашем и ещё двух голосах и завести баг. Если на стенде не воспроизводится — это уже кейс сессии, маршрут 2
Доступ оформлять не нужно: стенд открывается из офисной сети без заявок, там же можно послушать все голоса Сбера. С удалёнки не открывается, в том числе через Омегу — проверено 08.09 несколькими коллегами. На этом же стенде новые релизы TTS тестируют до выкатки

🧾Логи GigaVoiceиндекс найден 09.09, на нашем звонке не проверен

Индекс есть: filebeat-gigachat-gigavoice-gf-* в Kibana ИФТ — скриншоты Вяткина через Катю. Поиск по session id в кавычках, за одну сессию около 260 записей. В msg — trace-события (AUDIOSTREAM -> [synthesis_start], WMAPI -> [start_synthesize_response], TTS -> [session_finish]), состояния (preparing_for_speaking -> speaking_main_answer) и метрики строками Metric WM-API latency, Metric Full TTS. Текста реплик в msg нет; по словам GigaVoice, тексты лежат в unicode-escape и требуют декодирования — где именно, уточнить
⚠️ В индексах SkillFlow и PVS ИФТ обмена IVR ↔ GigaVoice нет — там только SkillFlow ↔ IVR. Тексты, ушедшие в TTS, видны в отладке IVR (онлайн) и в PVS IVR на ПРОМ (divrstat-ckr-tts-collect*)
Отдельной системы для этого нет: доступ тот же, что к 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 — совпадают ли эти значения, не проверено. Это главный открытый вопрос. Новая зацепка: в filebeat-gigachat-goprodigy* есть поле session-id — если туда попадает id голосовой сессии, request-id берётся из него, а request.string даёт полные messages
Чанки одного синтеза несут общий uuid с суффиксами _m, _n. Одна реплика ≠ одна строка
🚫 Доступ в среду разработки SmartIVR не запрашивать — это инструмент разработчиков, не пользовательский маршрут

🔑Пермишены GigaVoiceне запрашиваем

✅ Решено 08.09: не запрашиваем. Жалобы последнего времени только на интонацию синтеза, а её разбираем на стенде TTS. Ниже — справка на случай, если задержки снова станут темой
✅ Подтверждено 09.09: в индексе filebeat-gigachat-gigavoice-gf-* метрики уже лежат строками Metric WM-API latency, Metric Full TTS — серверные логи GigaVoice доступны через Kibana ИФТ, пермишены на отправку событий клиенту для анализа не нужны
Эти два списка управляют отправкой событий клиенту — то есть SmartIVR, который их ещё должен сохранить. Для анализа это другой путь
Порядок: получить Kibana → найти звонок по session-id → проверить, есть ли записи с metric_name и событие service_info. Обращаться только если их не окажется
UserIDsWithServiceInfoAccess — версия движка в сессии
UserIDsWithMetricAccess — asr_latency, gopro_latency, tts_latency, turn_taking_latency
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, и домен выбирается отдельным полем
Просмотр и выгрузка могут требовать разных контуров — уточнять оба отдельно
⏳ Не тот ВАРМ через ДРУГ — потеря недель

🔬После получения доступов — пройти цепочку самостоятельно

сценарий в business_value → sessionId → revisePOM, session, tts-collect → eduid → SCPL → запись — участок на ПРОМ показан Катей 09.09 целиком, осталось повторить под своей учёткой
session id → filebeat-gigachat-gigavoice-gf-* → session-id в goprodigy → request-id → request.string → wmcore — участок на ИФТ собран из скриншотов Вяткина, на нашем звонке не пройден
На том же эталонном звонке: мы знаем, что в нём было, поэтому сразу видно, чего в логах нет
Главный незакрытый участок — мост от звонка к request-id. Теперь есть где искать: поле session-id в filebeat-gigachat-goprodigy*. Если туда пишется id голосовой сессии, мост закрыт
Ключевое по промпту: сверить фактический контекст с тем, что отправил SkillFlow. Что отправил SkillFlow — видно в Kibana ИФТ целиком; что дошло до модели — пока не видно нигде. Собственного бизнес-промпта платформа не добавляет — проверяем, не задвоился ли наш промпт из конфига
При переданном silence_phrases_timeout в конец системного сообщения дописывается инструкция про пустое сообщение, а молчание пишется в историю как пара ходов, где ход клиента — пробел. Это одно из документированных платформенных дополнений к контексту: проверить, активна ли механика в нашем конфиге и нет ли других преобразований

⚠️Что не перепутать

СМД используется в проекте ещё и как источник исторических транскрибаций для персонализации. Это другая витрина и другая задача, технических логов не даст
Звонок на ПРЕДПРОМ для SkillFlow — боевой: промпт промовский, клиенты настоящие

Порядок

Разбор реальных обзвонов — через Voice360: текст, код завершения, запись. Уже работает
Сессия с Качаловой 09.09 прошла: индексы, поиск, SCPL и стенд TTS показаны, всё в разделе «Сессия с Качаловой». Из девяти вопросов закрыты семь; открыты индексы SkillFlow на ПРОМ, greenfield и запись SCPL на ИФТ
ИФТ, своими руками: Kibana → filebeat-nlp-dialog-policy-b2b-ift-7.x, номер в поиске, забрать session-id и промпт; PVS → …smapp.*. Затем filebeat-gigachat-gigavoice-gf-* по session id и filebeat-gigachat-goprodigy* по session-id → request-id → request.string. Если сработает — мост от звонка к запросу закрытсегодня
ПРОМ: проверить, открывает ли pvs-alpha-prod IVR-овский PVS smartivr-pvs.omega.sbrf.ru; если нет — спросить Катю, как оформлен её доступ. Заодно посмотреть, что лежит в pvs.sdmon.omega.sbrf.ru и Kibana Омега по нашему сценариюсегодня
ПРОМ, когда PVS IVR откроется: волна 28.08 в divrstat-ckr-business_value* по имени сценария — диалоги из revisePOM, кто положил трубку из session*, тексты TTS из tts-collect*, тайминги из phrases[].dateTime; проверить расчёт пауз по нимсегодня
SCPL: заявка в ДРУГ на ИФТ и Омегу. На ПРОМ запись ищется по eduid из PVS или по дате и номеру со звёздочкой; слушать в браузере, скачать нельзя
Стенд TTS: дефект на фразе — воспроизвести на нашем и ещё двух голосах, баг на стенде плюс ссылка в чат. Ударение чинится апострофом, но систематическое — отдавать Вяткину. Спросить его: проходят ли SSML-теги из текста модели в TTS, где в логах GigaVoice unicode-тексты реплик, наш greenfield
Не запрашиваем: Grafana, СМД как источник логов, Elastic по API, Dumper, пермишены GigaVoice — метрики уже видны в логах. Логи GigaChat отложены до ответа их команды по багу «функция без текста», но индексы goprodigy и wmcore известны
Витрины в Омеге и данные клиентов — Костя, отдельно от логов

Схема связей

Ключевое разделение. GigaVoice — оркестратор, а не модель. Неверная транскрибация — вопрос к ASR; верная транскрибация при кривом ответе — вопрос к GigaChat или к нашему промпту. Это позволяет делить дефекты по зонам ещё до обращения к смежникам. Второе разделение — по контурам: ИФТ показывает, что SkillFlow передал в IVR, но не реплики; текст диалога, завершение и ключ к записи есть только на ПРОМ. Дефекты синтеза воспроизводятся на стенде TTS, а не выкачиваются из звонка.

Пояснения к схеме

PVS · Kibana ИФТ

обмен SkillFlow ↔ SmartIVR · показано 09.09

Где: kibana.ift.sdmon.delta.sbrf.ru · pvs.ift.sdmon.delta.sbrf.ru
Внутри: Факт звонка, сценарий и интент, время, session-id, данные, переданные в IVR — промпт целиком и functions
Нет там: Текста диалога и кодов завершения: реплики и dialog_end ходят между IVR и GigaVoice мимо SkillFlow
Индексы: Kibana: filebeat-nlp-dialog-policy-b2b-ift-7.x. PVS: s.kib-ckr-text-va.smnlp-sf-ivr.smapp.*, остальные три — шум
Ключ: Номер телефона в строке поиска; фильтры args.channel: CCIVR_B2B, args.incoming_text: exists
Статус: доступ есть, поиск показан · Kibana удобнее, PVS только для багов связки SkillFlow ↔ IVR

Отладка SmartIVR

ИФТ · только онлайн

Внутри: Обмен IVR со всеми интеграциями, тексты на TTS — во время звонка
Нет там: Прошлых звонков: лог живой, постфактум не посмотреть
Статус: не нужен

PVS IVR · ПРОМ

контур Омега · самый информативный · показано 09.09

Где: smartivr-pvs.omega.sbrf.ru/pvs/ из VARM Alpha — PVS команды SmartIVR. Это не pvs.sdmon.omega.sbrf.ru из письма мониторинга
Индексы: divrstat-ckr-business_value* — диалог по ролям в revisePOM, «Результат звонка», шаги, eduid, OutboundContCommObj с таймингами реплик · services* — запросы и ответы сервисов · session* — кто завершил · tts-collect* — фразы на озвучку
Ключ: Имя сценария SALUT_agent_sales_outbound в поиске, sessionId в кавычках · eduid ведёт в SCPL
Завершение: near end disconnect — сценарий закрылся сам, far — положил клиент, transfer — перевод
Зачем: Кто положил трубку, тексты на TTS, код завершения и тайминги реплик — всё показано. Ничего из этого нет в Voice360
Кто: Качалова · диалоги 28.08 брали отсюда
Статус: проверить, пускает ли учётка pvs-alpha-prod · если нет — маршрут доступа у Кати

Voice360

витрина · ПРОМ · основной инструмент

Внутри: Весь диалог с ПРОМ, код завершения как «Результат звонка», там же прослушивание
Нет там: Call trace, таймингов ходов и текстов TTS — за этим в PVS IVR
Минус: Часть диалогов без транскрибации или с низким качеством; при необходимости — трек с командой Voice, прецедент с whisper есть
Связь: Данные приходят с ПРОМ. Витрины СМД — отдельно, для заказчиков, тексты в чистом виде
Статус: доступ есть

Аудиозаписи

SCPL · ИФТ и ПРОМ отдельно · показано 09.09

Где: b2b.scpl.omega.sbrf.ru из VARM Alpha · доступ через ДРУГ на оба контура
Ключ: «ID взаимодействий» = eduid из PVS IVR; сегмент нашего сценария со значком записи, его ID = sessionId. Или дата плюс номер со звёздочкой
Слушать: подтверждено · «Статистика по взаимодействиям» → слушать
Скачать: штатно нет — Катя пишет на диктофон
2 дорожки: нет — запись одна, смешанная
ИФТ: Сначала проверить, что запись для проекта включена

Стенд TTS

GigaVoice · дефекты синтеза · SSML показан 09.09

Где: webfront-dev.cloud.delta.sbrf.ru/tts/ · стенд IFT_GIGA_TTS_v100
Что: Ввести текст, выбрать голос и качество 8000, послушать; баг заводится прямо со стенда, ссылку — в чат GigaVoice
SSML: Ударение — апостроф перед гласной в <speak>; эмоция — <voice mode="happy">; пауза — break_time. IVR теги пропускает; из текста модели — «по идее», спросить Вяткина
Правило: Прогонять фразу 2–3 раза — синтез плавает. Кейс из сессии стендом не закрывается: форма с контуром, greenfield, session_id и аудио
Кто: Вяткин, Головин · Катя тестирует кейсы сама, просит присылать
Статус: открывается из офиса без заявок · с удалёнки нет

Логи GigaVoice

Kibana ИФТ · индекс найден 09.09

Индекс: filebeat-gigachat-gigavoice-gf-* — по скриншотам Вяткина; gf — greenfield примера, наш уточнить
Внутри: Trace-события синтеза и состояний, строки Metric WM-API latency, Metric Full TTS, старт и финиш сессии TTS
Ключ: session id в кавычках в строке поиска
Нет там: Текста реплик в msg; по словам GigaVoice, тексты в unicode-escape — где, уточнить
Статус: индекс есть, на нашем звонке не проверен

Логи GigaChat

Kibana ИФТ · индексы найдены 09.09

Индексы: filebeat-gigachat-goprodigy* — шлюз: request-id, session-id, модель, request.string с полными messages · filebeat-gigachat-wmcore-ift-7.x — ядро, по request_id
Ключ: request-id; зацепка для моста — session-id в goprodigy
Доступ: Тикет SDMON-5160, закрыт за 13 минут
Проверено: Пример Вяткина — запрос из python-клиента, не от звонка
Решение: Отложено как трек с командой GigaChat; для моста от звонка индексы уже нужны
Статус: доступ есть, мост не пройден

Пермишены GigaVoice

не запрашиваем

Даёт: service_info — версия движка в сессии
metric — asr_latency, gopro_latency, tts_latency, turn_taking_latency
CN: CI03219423-IFT-CORP
CI03219423-PROM-kiparis-ckr
Кто: Головин, Вяткин
Учесть: Латенси уже видны в filebeat-gigachat-gigavoice-gf-* строками Metric … — пермишены не нужны, подтверждено 09.09
Статус: не запрашиваем

подтверждено частично / требует проверки нужно запросить неизвестно

Что учесть

На ИФТ текста нет

Kibana и PVS ИФТ видят только обмен SkillFlow ↔ IVR. Реплики ходят между IVR и GigaVoice и на ИФТ видны только в отладке, онлайн. Voice360 тоже только про ПРОМ. Разбор реплик — по ПРОМ.

Сначала смотрим, потом спрашиваем

Почти всё, что хотелось уточнить у коллег, видно в логах самому. Обращение после проверки будет предметным: вот звонок, вот индекс, вот чего в нём нет.

ПРЕДПРОМ — это ПРОМ

У IVR три контура, у SkillFlow два. Звонок на ПРЕДПРОМ идёт по боевому сценарию SkillFlow. Менять и тестировать быстро можно только на ИФТ.

PVS — это не СМД

PVS — интерфейс просмотра и поиска, витрина СМД — источник и подписка для заказчиков. Voice360 — витрина с диалогом и записью, данные туда попадают с ПРОМ.

ИФТ и ПРОМ просят по-разному

На ИФТ — свободный тикет, и формулировка узкая: только Kibana. На ПРОМ — форма, и она открывает одну комбинацию: выбрали Kibana — Grafana пропала из списка. Grafana при необходимости подаётся отдельно. Учётки PVS на ИФТ и ПРОМ тоже разные.

Два PVS на ПРОМ

PVS мониторинга SberDevices — pvs.sdmon.omega.sbrf.ru, туда выдана учётка pvs-alpha-prod. PVS команды SmartIVR — smartivr-pvs.omega.sbrf.ru, там паттерны divrstat-ckr-* с диалогами. Катя показывала второй; открывает ли его наша учётка — проверить.

Одна дорожка

Запись звонка одна, смешанная; скачать её штатно нельзя — пишут на диктофон, встроенного нет. Дефект на фразе — стенд TTS. Кейс из сессии — форма и аудио с SCPL.

Kibana Омега не нужна

Всё по звонку есть в PVS IVR; Kibana на ПРОМ — только если подозрение, что отправленное в NLP отличается от прилетевшего. По опыту Кати не отличается.

Тайминги — не из tts-collect

В tts-collect все фразы звонка записаны одним временем в конце. Реальные метки реплик — phrases[].dateTime в OutboundContCommObj.

Dumper — не решение для аудио

Только входящий клиентский звук; дорожка синтеза не гарантирована. Может затронуть весь трафик инстанса. Команда сценариев им не пользуется. Уместен, похоже, только на ИФТ и только после согласования.

Две разные витрины СМД

Нужна витрина с результатами звонков. Историческая витрина транскрибаций для персонализации — другая задача, технических логов не даст.

Кто за что отвечает

Кто	Зона	С чем идти
Екатерина Качалова	PVS ИФТ и ПРОМ, логи IVR, запись, Voice360, сценарий SkillFlow	Сессия 09.09 прошла, всё показано. Осталось: как оформлен её доступ к `smartivr-pvs.omega.sbrf.ru`, ссылка на PVS IVR на ИФТ (ждёт от коллеги из IVR), индексы SkillFlow на ПРОМ, запись SCPL на ИФТ. Изменения сценария и промпта на ПРОМ идут через неё; просит присылать интересные кейсы синтеза
Виктор Вяткин Павел Головин	GigaVoice · синтез, дефекты, логи	Стенд TTS: баг на стенде плюс ссылка в чат, доступ не оформляется. Кейс из сессии: форма с контуром, greenfield, `session_id` и аудио. Вопросы после 09.09: проходят ли SSML-теги из текста модели в TTS; где в логах GigaVoice unicode-тексты реплик и как их декодировать; наш greenfield; попадает ли id голосовой сессии в `session-id` индекса `goprodigy`
Егор Кулагин Алексей Колокольников	ЦКР · аудиокейсы для GigaVoice	Как записывают аудиокейс — по словам Кати, обычным диктофоном; спрашивать только если понадобится кейс из сессии
Павел Головин Виктор Вяткин	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	Баг «вызов функции без возврата текста»: логи отправлены, после первых ответов реакции нет. Пока обходим в промпте
Константин Медведев	Витрины в Омеге, данные клиентов	ПКАП ММБ, уровни доверия, история взаимодействия — для персонализации и оцифровки эффективности. Проходит доступы первым, потом расскажет
Лаборатория данных	Подписка на витрину	Оформление подписки на названный поток СМД