Распознавание и анализ разговоров
2012-07-05 07:45 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapovВ продолжение вчерашней дискуссии.
Допустим, мы как-то распознаем разговоры и сохраняем получившийся текст. Я намерено не хочу сейчас касаться ни качества "аудио", которое придется распознавать, ни качества получающегося в результате текста. Пусть даже тут у нас все будет идеально.
Расскажите мне пожалуйста, что с этими текстами делать потом? (напомню, что мы говорим про Кровавый Режим, который надеется получить с этого какой-то профит).
Суммируя вчерашние аргументы, были названы такие цели:
1)использовать тексты для бинарной классификации (террорист - не террорист, протестующий - не протестующий)
2)использовать тексты для последующего полнотекстового поиска (с целью той же бинарной классификации, но без четких критериев)
3)складировать тексты про запас с тем, чтобы потом читать про тех, кто "попал на карандаш".
Мне кажется, что для всех трех целей запись и распознавание всех разговоров будут ужасно неэффективным средством. По пунктам:
Классификация
=============
Как учить такой классификатор? Откуда взять training set тех самых true positive целевых разговоров достаточного объема?
У классификатора будут ужасные precision и recall - что с этим делать? Поясню: классы будут сильно перекошены по размеру (1 террорист на пару миллионов обычных людей), соответственно, любые неточности классификации в сумме с false positives приведут к тому, что классификатор будет практически бесполезен. Допустим, мы с вероятностью в 30% не узнаем нужный единственный разговор из миллиона, зато с вероятностью 0.01% тыкаем пальцем в ненужный - посчитайте сами, что мы получим на выходе.
Кроме того, критерии классификации - не фиксированы (сегодня ищем "химию", завтра - "болотную"), соответственно, надо постоянно создавать и учить новые классификаторы. Это сложно и вычислительно и организационно (выбор хороших критериев).
Использовать же unsupervised методы, как мне кажесят, не получится из-за размерности простанства. Грубо говоря - у нас слишком много всех возможных слов и разговоров, чтобы какой-то unsupervised алгоритм это прошерстил. Да и на выходе мы получим слишком много классов, которые потом надо будет обработать вручную. Добавим к этому, что почти наверняка нужный "один разговор из миллиона" будет объединен в один класс с мешком других, и получаем на выходе один пшик.
Полнотекстовый поиск
====================
Учитывая, что целевая аудитория (гипотетические "террористы") шифруется, поиск надо будет вести по неуникальным, "бытовым" словам. Любой желающий может поиграть с гуглом и поскать "террористов" там, и увидеть, насколько это безнадежная затея.
Читать постфактум
=================
Казалось бы, какие тут могут быть возражения - бери и читай? Но для начала надо сгруппировать разговоры "по людям", то есть вместо "это разговор между номерами А и Б" получить "это разговор между Ивановым и Петровым", и потом уже читать все разговоры Иванова. При это _надо_ исходить из предположения, что владелец контракта и тот, кто реально говорит по телефону - это могут быть разные люди. Я верю, что подобная задача решается в условиях ограниченного количества людей и аудиозаписей, но для всех-всех-всех разговоров - нереально.
Итого
=====
Вагон затрат (особенно временных), минимальный (неотличимый от нуля) выхлоп. Если бы было социально приемлемо прослушивать всех подряд, из этого вышел бы хороший PR-проект (или, иначе, security theatre) - смотрите, мол, как у нас граница на замке. Ни одна мышь не проскочет - у нас этажи сервером и кубометры винчестеров, всех поймаем. Делать же это втайне, надеясь получить какой-то результат - глупо.
Discuss?
Допустим, мы как-то распознаем разговоры и сохраняем получившийся текст. Я намерено не хочу сейчас касаться ни качества "аудио", которое придется распознавать, ни качества получающегося в результате текста. Пусть даже тут у нас все будет идеально.
Расскажите мне пожалуйста, что с этими текстами делать потом? (напомню, что мы говорим про Кровавый Режим, который надеется получить с этого какой-то профит).
Суммируя вчерашние аргументы, были названы такие цели:
1)использовать тексты для бинарной классификации (террорист - не террорист, протестующий - не протестующий)
2)использовать тексты для последующего полнотекстового поиска (с целью той же бинарной классификации, но без четких критериев)
3)складировать тексты про запас с тем, чтобы потом читать про тех, кто "попал на карандаш".
Мне кажется, что для всех трех целей запись и распознавание всех разговоров будут ужасно неэффективным средством. По пунктам:
Классификация
=============
Как учить такой классификатор? Откуда взять training set тех самых true positive целевых разговоров достаточного объема?
У классификатора будут ужасные precision и recall - что с этим делать? Поясню: классы будут сильно перекошены по размеру (1 террорист на пару миллионов обычных людей), соответственно, любые неточности классификации в сумме с false positives приведут к тому, что классификатор будет практически бесполезен. Допустим, мы с вероятностью в 30% не узнаем нужный единственный разговор из миллиона, зато с вероятностью 0.01% тыкаем пальцем в ненужный - посчитайте сами, что мы получим на выходе.
Кроме того, критерии классификации - не фиксированы (сегодня ищем "химию", завтра - "болотную"), соответственно, надо постоянно создавать и учить новые классификаторы. Это сложно и вычислительно и организационно (выбор хороших критериев).
Использовать же unsupervised методы, как мне кажесят, не получится из-за размерности простанства. Грубо говоря - у нас слишком много всех возможных слов и разговоров, чтобы какой-то unsupervised алгоритм это прошерстил. Да и на выходе мы получим слишком много классов, которые потом надо будет обработать вручную. Добавим к этому, что почти наверняка нужный "один разговор из миллиона" будет объединен в один класс с мешком других, и получаем на выходе один пшик.
Полнотекстовый поиск
====================
Учитывая, что целевая аудитория (гипотетические "террористы") шифруется, поиск надо будет вести по неуникальным, "бытовым" словам. Любой желающий может поиграть с гуглом и поскать "террористов" там, и увидеть, насколько это безнадежная затея.
Читать постфактум
=================
Казалось бы, какие тут могут быть возражения - бери и читай? Но для начала надо сгруппировать разговоры "по людям", то есть вместо "это разговор между номерами А и Б" получить "это разговор между Ивановым и Петровым", и потом уже читать все разговоры Иванова. При это _надо_ исходить из предположения, что владелец контракта и тот, кто реально говорит по телефону - это могут быть разные люди. Я верю, что подобная задача решается в условиях ограниченного количества людей и аудиозаписей, но для всех-всех-всех разговоров - нереально.
Итого
=====
Вагон затрат (особенно временных), минимальный (неотличимый от нуля) выхлоп. Если бы было социально приемлемо прослушивать всех подряд, из этого вышел бы хороший PR-проект (или, иначе, security theatre) - смотрите, мол, как у нас граница на замке. Ни одна мышь не проскочет - у нас этажи сервером и кубометры винчестеров, всех поймаем. Делать же это втайне, надеясь получить какой-то результат - глупо.
Discuss?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2012-07-06 06:39 am (UTC)Сформировать произвольное синтетическое ID, конечно же, очень легко, но толку от него будет 0. Мы же хотим, чтобы ID идентифицировало говорящего, а не номер, так?
(no subject)
Date: 2012-07-06 07:34 am (UTC)и зачем идентифицировать говорящего? то, что нужно органам - это записи разговоров конкретных номеров за конкретное время. в настоящее время с известной степенью достоверности можно установить владельцев только контрактных номеров.
(no subject)
Date: 2012-07-06 08:58 am (UTC)Для постпейда надо хранить какую-то небольшую часть информации, которую дает коммутатор (кто, кому, когда). Но всякие технические подробности (какая базовая, какой транк, ...) там не нужны.
Сооветственно, чтобы делать выборку "кто звонил тогда-то через такую-то базовую" ни припейд платформа, ни биллинг не подходят.
А других баз может и не быть (так как оператору нафиг не надо хранить ВСЕ). Может быть только большая файлопомойка, выборка из которой делается полным перебором всех файлов за конкретный день, например. Что вполне удовлетворяет текущим требованиям к операторам ("давать распечатку данных о звонках"), но не расширяется до "хранить все записи звонков".
(no subject)
Date: 2012-07-06 10:52 am (UTC)для постпейда технические подробности не нужны абоненту, но они хранятся для каких-то других целей. за продолжительность хранения технических событий тоже не скажу, запросы видел, а что на них отвечали - не знаю. наверное был отказ в духе "такого не храним".
да и не нужно МВД делать выборки через какую базовую звонил Иван Иваныч и что он сказал на базовой такой-то. тем более при включенном хоппинге и/или на оборудовании некоторых производителей это бессмысленно.
хранить всё и вечно - не обязательно, даже сейчас хранятся события только за определённое время. в маленьких системах, типа астериска, этот механизм относительно легко реализуется, в больших, конечно, сложнее. сложность, главным образом в том, наверное, что в том месте, где нужно писать, нет дисковых хранилищ и оборудования/софта для записи. кроме, пожалуй, huawei). эти что угодно напишут, пусть и кривовато.
(no subject)
Date: 2012-07-06 11:10 am (UTC)Да, но они хранятся вовсе не там, где происходит рейтинг и биллинг. Ровно о чем я и написал.
Все, что я хотел сказать - что совершенно не очевидно, что эти запросы удовлетворяются "запросами из базы", в которую, следовательно, можно вставить еще какое-то поле или с чем-то там ее связать. База может быть, а может и не быть. Просто не нужно считать, что она обязательно есть.
Нужно-нужно. "В районе ул. Такой-то и Сякой-то в промежутке с 17:00 до 19:00".
(no subject)
Date: 2012-07-06 11:30 am (UTC)(no subject)
Date: 2012-07-06 12:09 pm (UTC)(no subject)
Date: 2012-07-06 04:55 pm (UTC)кстати, ещё один источник мифов - ПО для записи разговоров. "активистам" бывает проще верить в кровавый режим, чем учиться пользоваться собственным телефоном.