Распознавание и анализ разговоров

[dastapov]

В продолжение вчерашней дискуссии.

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

Расскажите мне пожалуйста, что с этими текстами делать потом? (напомню, что мы говорим про Кровавый Режим, который надеется получить с этого какой-то профит).

Суммируя вчерашние аргументы, были названы такие цели:
1)использовать тексты для бинарной классификации (террорист - не террорист, протестующий - не протестующий)
2)использовать тексты для последующего полнотекстового поиска (с целью той же бинарной классификации, но без четких критериев)
3)складировать тексты про запас с тем, чтобы потом читать про тех, кто "попал на карандаш".

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

Классификация
=============
Как учить такой классификатор? Откуда взять training set тех самых true positive целевых разговоров достаточного объема?

У классификатора будут ужасные precision и recall - что с этим делать? Поясню: классы будут сильно перекошены по размеру (1 террорист на пару миллионов обычных людей), соответственно, любые неточности классификации в сумме с false positives приведут к тому, что классификатор будет практически бесполезен. Допустим, мы с вероятностью в 30% не узнаем нужный единственный разговор из миллиона, зато с вероятностью 0.01% тыкаем пальцем в ненужный - посчитайте сами, что мы получим на выходе.

Кроме того, критерии классификации - не фиксированы (сегодня ищем "химию", завтра - "болотную"), соответственно, надо постоянно создавать и учить новые классификаторы. Это сложно и вычислительно и организационно (выбор хороших критериев).

Использовать же unsupervised методы, как мне кажесят, не получится из-за размерности простанства. Грубо говоря - у нас слишком много всех возможных слов и разговоров, чтобы какой-то unsupervised алгоритм это прошерстил. Да и на выходе мы получим слишком много классов, которые потом надо будет обработать вручную. Добавим к этому, что почти наверняка нужный "один разговор из миллиона" будет объединен в один класс с мешком других, и получаем на выходе один пшик.


Полнотекстовый поиск
====================

Учитывая, что целевая аудитория (гипотетические "террористы") шифруется, поиск надо будет вести по неуникальным, "бытовым" словам. Любой желающий может поиграть с гуглом и поскать "террористов" там, и увидеть, насколько это безнадежная затея.

Читать постфактум
=================

Казалось бы, какие тут могут быть возражения - бери и читай? Но для начала надо сгруппировать разговоры "по людям", то есть вместо "это разговор между номерами А и Б" получить "это разговор между Ивановым и Петровым", и потом уже читать все разговоры Иванова. При это _надо_ исходить из предположения, что владелец контракта и тот, кто реально говорит по телефону - это могут быть разные люди. Я верю, что подобная задача решается в условиях ограниченного количества людей и аудиозаписей, но для всех-всех-всех разговоров - нереально.

Итого
=====

Вагон затрат (особенно временных), минимальный (неотличимый от нуля) выхлоп. Если бы было социально приемлемо прослушивать всех подряд, из этого вышел бы хороший PR-проект (или, иначе, security theatre) - смотрите, мол, как у нас граница на замке. Ни одна мышь не проскочет - у нас этажи сервером и кубометры винчестеров, всех поймаем. Делать же это втайне, надеясь получить какой-то результат - глупо.

Discuss?

Comments

[ghrar.livejournal.com]

сейчас МВД имеет ограниченный набор средств для снятия отпечатков. чаще всего для этого используются расходные материалы и большое количество времени для аккуратной работы, дабы не смазать отпечаток.
всё остальное за скобками: оцифровать, каталогизировать, поместить в БД и организовать по ней поиск - уже решено и внедрено.
аналогично с тотальным видеонаблюдением. да, пилотный проект распознавания лиц в США потерпел крах, но зная, что где-то произошло преступление можно просто взять видео за интересующий период времени и детально отсмотреть человеческим ресурсом. а видео требует значительно больше места для хранения, чем аудио).

[http://users.livejournal.com/_adept_/]

У видео есть одно существенное отличие - камера стоит себе на месте. Она не двигается, у нее не меняется владелец (точнее, его вообще нет).

А телефонные номера и imsi включаются, отключаются, переносятся между контрактами и т.п. Любое массовое решение по "записи всего" должно это учитывать и коррелировать хренову тучу истории.

[http://users.livejournal.com/_adept_/]

Для биллинга ситуация чуть попроще. Биллингу пофиг, реальные люди. Для биллинга важно посчитать _аггрегированные_ данные по контракту, и все.

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

Биллингу все равно, что Иван Иванов владеет 5 симками, но говорит реально только по одной, а по остальным говорят его сотрудники. И так далее. То есть биллингу надо только разбираться с историей смен номеров телефона и сим-карт за ограниченный период времени. Все эти смены, что важно, делаются через биллинговую же систему, и вся история таким образом в ней уже есть.

В препейде вообще все просто. Сняли деньги с баланса на ходу и никакой возни с историей.

А вот чтобы связывать разговоры с реальными _людьми_ нужно поработать чуть основательнее (в случае постпейда) или вообще по-другому (в случае припейда).

И забивать на такие частности нельзя, а то не получится универсального, работающего годами решения.

[norguhtar.livejournal.com]

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

[norguhtar.livejournal.com]

В том что архив живет отдельно. К примеру на магнитной ленте в запакованном виде. Значит его надо восстановить. А это уже ручная операция.

[norguhtar.livejournal.com]

и что, операторы каждый раз при подключении каждого абонента лезут в архив ручками ?

Вы не поняли. Есть минимальная информация о клиенте. А вот к примеру куда он звонил год назад уже нет. Или детализация начислений есть только за месяц.

[http://users.livejournal.com/_adept_/]

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

Как бы то ни было, долги собираются отнюдь не в момент переподключения.

[http://users.livejournal.com/_adept_/]

Кстати про скорость: как вы считаете, с какой скоростью надо оцифровывать разговоры, чтобы хотя бы успевать (в масштабах России)? И чтобы можно было на день выключить систему для апгрейда или чего-то подобного и не получить "хвост", который придется разгребать месяц.

Если у вас получилась цифра - как вы ее посчитали?

[ziavra.livejournal.com]

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

[ghrar.livejournal.com]

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

[http://users.livejournal.com/_adept_/]

Может потребоваться еще эту самую запись создать (препейд), или завести какие-то синтетические ID (люди с N контрактами)

[ghrar.livejournal.com]

записи в биллинге и так создаются, ведь распечатка звонков предоставляется же). и хотя я не сильно копенгаген в базах данных, но добавить дополнительное поле и сформировать автоматически уникальное имя каждой записи - не проблема. опять же удобно - аудиозапись разговора будет одна на двоих и запись в БД будет одинаковая.
и синтетические id создавать не обязательно, ведь сейчас запросы из мвд приходят чаще без фамилий), тайна следствия, видите ли). да и не факт, что говорить будут именно владельцы контрактов.

[http://users.livejournal.com/_adept_/]

Для препейда может не быть никакой биллинговой записи, так как нету bill-а (счета). Может быть баланс в SCP (это такая железка рядом с коммутатором) и все.

Сформировать произвольное синтетическое ID, конечно же, очень легко, но толку от него будет 0. Мы же хотим, чтобы ID идентифицировало говорящего, а не номер, так?

[ghrar.livejournal.com]

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

[http://users.livejournal.com/_adept_/]

Краеугольная цель у оператора - посчитать деньги. Для препейда деньги считаются на ходу, и вообще ничего о звонках для этого хранить не надо. Чтобы отвечать на вопросы пользователей, достаточно хранить последний месяц, или вообще последние 10-20 звонков.

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

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

А других баз может и не быть (так как оператору нафиг не надо хранить ВСЕ). Может быть только большая файлопомойка, выборка из которой делается полным перебором всех файлов за конкретный день, например. Что вполне удовлетворяет текущим требованиям к операторам ("давать распечатку данных о звонках"), но не расширяется до "хранить все записи звонков".

[ghrar.livejournal.com]

не мне Вам, Дмитрий, рассказывать, что даже для препейда хранятся записи более чем за месяц). и успешные ответы оператора на запросы МВД тому свидетельство. в прошлом году у мтс можно было получить распечатку своих звонков за последние три месяца бесплатно в рамках тестирования интернет-помощника).
для постпейда технические подробности не нужны абоненту, но они хранятся для каких-то других целей. за продолжительность хранения технических событий тоже не скажу, запросы видел, а что на них отвечали - не знаю. наверное был отказ в духе "такого не храним".
да и не нужно МВД делать выборки через какую базовую звонил Иван Иваныч и что он сказал на базовой такой-то. тем более при включенном хоппинге и/или на оборудовании некоторых производителей это бессмысленно.
хранить всё и вечно - не обязательно, даже сейчас хранятся события только за определённое время. в маленьких системах, типа астериска, этот механизм относительно легко реализуется, в больших, конечно, сложнее. сложность, главным образом в том, наверное, что в том месте, где нужно писать, нет дисковых хранилищ и оборудования/софта для записи. кроме, пожалуй, huawei). эти что угодно напишут, пусть и кривовато.

[http://users.livejournal.com/_adept_/]

е мне Вам, Дмитрий, рассказывать, что даже для препейда хранятся записи более чем за месяц)

Да, но они хранятся вовсе не там, где происходит рейтинг и биллинг. Ровно о чем я и написал.

запросы видел, а что на них отвечали - не знаю. наверное был отказ в духе "такого не храним".

Все, что я хотел сказать - что совершенно не очевидно, что эти запросы удовлетворяются "запросами из базы", в которую, следовательно, можно вставить еще какое-то поле или с чем-то там ее связать. База может быть, а может и не быть. Просто не нужно считать, что она обязательно есть.

да и не нужно МВД делать выборки через какую базовую звонил Иван Иваныч и что он сказал на базовой такой-то. тем более при включенном хоппинге и/или на оборудовании некоторых производителей это бессмысленно.

Нужно-нужно. "В районе ул. Такой-то и Сякой-то в промежутке с 17:00 до 19:00".

[ghrar.livejournal.com]

за Россию не скажу, а в Украине таких запросов не пробегало.

[http://users.livejournal.com/_adept_/]

а я вот видел своими глазами и даже данные выбирал :)

[ghrar.livejournal.com]

охотно верю). ибо запрос на предоставление содержимого gprs-сессий для конкретного номера за максимально возможный срок я видел). его, естественно, не удовлетворили. и вопросы на тему "а как бы мне от оператора получить мои собственные разговоры" тоже появлялись.
кстати, ещё один источник мифов - ПО для записи разговоров. "активистам" бывает проще верить в кровавый режим, чем учиться пользоваться собственным телефоном.