Поиск по звонкам: найти реплику и проверить её контекст

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

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

Когда поиск по звонкам находит слово, а не ответ

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

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

Если ваша задача — проверить поиск по разговорам, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Реплика без роли — это половина цитаты

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

У реплики должны быть атрибуты, без которых цитата становится опасной. Роль говорящего (клиент, менеджер, третье лицо на линии). Время начала и конца. Идентификатор звонка и ссылка на исходную запись. Статус расшифровки — черновая, проверенная, исправленная вручную. Версия модели или словаря, которой сделана расшифровка. Если этих полей нет, поиск выдаёт строки, но не даёт ответить на вопрос «кто это сказал и можно ли этому верить».

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

Буквальное совпадение и смысловое — разные инструменты под разные вопросы

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

Механика точного совпадения описана в документации Elastic по match query: запрос разбивается на термы, и документ считается подходящим по правилам оператора (все термы, любой терм, доля термов). Это важно понимать при настройке: если по умолчанию стоит «любой терм», запрос из трёх слов вернёт всё, где встретилось хотя бы одно. Для коротких реплик это допустимо, для длинных разговоров — источник мусора в выдаче.

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

Подсветка совпадения: где заканчивается польза и начинается иллюзия

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

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

Есть и обратная крайность: подсветить весь абзац, чтобы «наверняка». Тогда глаз цепляется за десять маркеров и теряет главный. Разумный компромисс — подсвечивать точное совпадение и показывать одно-два предложения вокруг, а полную реплику раскрывать по клику. Это экономит внимание при просмотре списка и не мешает углубиться в конкретный случай.

Таймкод как дверь в исходник

Цитата без возможности услышать оригинал — это пересказ, а не доказательство. Расшифровка ошибается: имена, числа, отрицания, диалекты. Поэтому у каждого результата должна быть дверь обратно в аудио — на конкретную секунду. Google Cloud в документации по word time offsets показывает, как распознавание возвращает время для каждого слова: это позволяет ставить метку не на реплику целиком, а на нужное слово, чтобы плеер открывался за пару секунд до него.

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

Второй нюанс — исправленный транскрипт. Если оператор вручную поправил расшифровку (уточнил имя, поправил сумму), поиск должен индексировать актуальную версию, а не исходную машинную. Иначе получится, что в интерфейсе цитата выглядит правильно, а поиск по ней не находит, потому что индекс отстал. Версионирование расшифровки и переиндексация при правке — не роскошь, а условие предсказуемости.

Отрицание, синоним и чужая роль: три ловушки одной выдачи

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

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

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

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

Выдача реплик из звонков: что должно лежать в индексе

Чтобы всё перечисленное не осталось теорией, зафиксируем форму записи, с которой работает поиск. Это не схема базы данных, а минимальный набор полей, без которых цитата теряет проверяемость.

Поле уверенности распознавания стоит показывать не числом, а меткой: «надёжно», «проверить», «низкое качество». Менеджер не будет интерпретировать 0,87, а метку поймёт сразу. Это снижает риск, что ошибочно распознанное «не дорого» превратится в «дорого» в чьём-то отчёте.

Отдельно решается вопрос с одинаковыми репликами в разных звонках. Фраза «здравствуйте, меня зовут Анна» встретится в сотне записей. Поиск должен схлопывать такие повторы в группы с указанием числа звонков либо позволять исключать типовые реплики из выдачи, иначе первая страница — это приветствия, а суть на пятой. Иначе первая страница выдачи — это приветствия, а суть на пятой.

Два эпизода: где поиск помог и где подвёл

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

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

Мораль обоих эпизодов одна: поиск по звонкам — это инструмент проверки гипотезы, а не её источник. Гипотезу формулирует человек, поиск помогает её подтвердить или опровергнуть, а исходник позволяет убедиться, что цитата не вырвана из контекста.

Выдача реплик из звонков: исключения и проверка условий

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

Нет аудио. Запись удалена по политике хранения, расшифровка осталась. Поиск находит цитату, но проверить её на слух нельзя. Решение — явная метка и, если политика позволяет, хранение расшифровок дольше аудио. Но это вопрос внутренних правил, а не функции поиска.

Старый исправленный транскрипт. Оператор поправил расшифровку месяц назад, а индекс не пересобрался. Поиск ведёт на устаревшую версию. Лечится переиндексацией при правке и хранением версий, чтобы можно было понять, что именно изменилось.

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

Смена говорящего внутри реплики. Диаризация ошиблась, и две реплики склеились в одну. Тогда «дорого» клиента и «не дорого» менеджера окажутся в одном фрагменте, и роль будет неверной. Единственная защита — возможность ручной правки ролей и пометка «роль под вопросом».

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

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

Выдача реплик из звонков на экране сотрудника

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

В выдаче каждый результат — это карточка: цитата с подсветкой, роль, время, ссылка на звонок, метка уверенности. Рядом — кнопка «открыть на этой секунде». Если аудио нет, кнопка неактивна и есть пояснение. Если реплика исправлена вручную, стоит маленькая пометка «проверено оператором». Такие детали не украшают интерфейс, а снижают число неверных выводов.

Отдельно стоит продумать пустой результат. «Ничего не найдено» — плохой ответ, если запрос был смысловым и близкие реплики есть. Полезнее показать: «точных совпадений нет, но есть похожие по смыслу» — и дать их список с пометкой, что это не буквальное совпадение. Так пользователь понимает, что именно он искал и почему не нашёл.

Как проверить поиск перед тем, как на него полагаться

Проверка не требует больших данных. Достаточно набора из десятка звонков, где вы вручную знаете, что и где сказано. Дальше — прогон по сценариям, которые чаще всего ломают выдачу.

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

Практикум: один запрос, три режима, честный вывод

Возьмём условную ситуацию, отличную от предыдущих. Компания продаёт онлайн-курсы, отдел из четырёх менеджеров, записи хранятся месяц. Руководитель хочет понять, почему клиенты не доходят до оплаты после первого звонка. Он формулирует три запроса и прогоняет их по одному и тому же периоду.

Первый запрос — точное совпадение по слову «подумаю». Выдача — тридцать реплик, почти все от клиентов. Руководитель видит, что «подумаю» часто звучит в конце разговора, после того как менеджер назвал цену. Это сигнал, но не ответ: «подумаю» может означать и сомнение в цене, и сомнение в необходимости курса.

Второй запрос — смысловое совпадение по фразе «не уверен, что мне это подходит». Выдача — двенадцать реплик, часть из них — вопросы клиентов о содержании курса, часть — сомнения в уровне. Здесь руководитель замечает, что клиенты не понимают, для какого уровня подготовки курс. Это уже конкретная гипотеза.

Третий запрос — точное совпадение по названию курса с фильтром по роли «клиент». Выдача — сорок реплик, в основном вопросы о формате. Руководитель видит, что клиенты путают формат: думают, что это живой вебинар, а не записи.

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

Что остаётся за пределами поиска

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

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

Смежный вопрос разобран отдельно: Голос клиента: как собрать инсайты из 100% разговоров.