Наверх ▲

Практическое применение семантического анализа для фильтрации трафика

Михаил Волович Михаил Волович Признанный эксперт в лингвистике, лексикограф, специалист по интеллектуальным технологиям и юзабилити сайтов. Яков Маркович Яков Маркович Ведущий программист в компании "Ашманов и партнеры".

Яков Маркович: Я представляю компанию "Ашманов и партнеры". Сегодня я расскажу о разработанном нами веб-фильтре "Ремпаро", который применяют для фильтрации содержимого в Интернете, используя семантический анализ текста.

Задача фильтрации контента в Интернете сейчас оказалась достаточно насущной. Необходима защита детей от всякого нехорошего контента. Самый простой пример такого контента – порно. Но к категории нежелательных можно отнести и сайты, посвященные самоубийствам, наркотикам, экстремизму и так далее.

На самом деле, тема веб-фильтрации достаточно разработана.

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

  • Где фильтруется? На локальной машине или на сервере (на сервере или на "клиенте").
  • Каким образом фильтруется? Каким образом определяется, "плохой" или "хороший" контент.
  • Объем обработки, производительность (хотя это напрямую связано с первой осью).

Существует два основных способа фильтрации:

  • фильтрация по спискам URL и IP;
  • фильтрация по содержимому, собственно, контенту.

Фильтрация по URL наиболее распространена. Она обладает следующими основными недостатками. Во-первых, количество ресурсов в Интернете бесконечно, а база URL, как вы понимаете, конечна. Во-вторых, существует проблема миграции ресурсов.

Самая главная проблема современного Интернета – то, что он динамический, и то, что существует интернет 2.0 – всевозможные социальные сети и тому подобные вещи, которые никоим образом фильтрации по IP или URL не поддаются.

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

Конечно, наш фильтр также умеет работать традиционными методами, то есть по спискам URL и IP, используя их как вспомогательные. Но ядром, "сердцем" нашего фильтра является технология фильтрации по содержимому.

Мы извлекаем текст из всего, из чего он, вообще говоря, может быть извлечен. Иногда из того, из чего он извлечен быть не может. HTML, Flash, могут подключаться плагины для любых текстовых или текстоподобных документов. Вы удивитесь: на самом деле, даже из фильмов можно иногда извлекать тексты. С помощью фирменной технологии "семантическое зеркало" мы классифицируем этот текст.

Чем же замечательна технология "семантического зеркала"?

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

В нашей технологии после анализа текста мы получаем семейство иерархических категорий. Не ответ, плохой это текст или хороший, и даже не одну категорию ("наркотики", "порно"). Мы получаем приписанный к тексту набор иерархических категорий. Мало того, у каждой категории есть некий индекс релевантности, который говорит о том, что этот текст не только об этом, но еще и насколько именно об этом данный текст.

Категорий может быть несколько. Если у нас идет категория, говорящая о том, что этот текст о сексе – это может быть текст о сексуальном воспитании, порнография и тому подобное.

Собственно технология семантического зеркала состоит из двух частей:

  • из лингвистического "движка", который занимается лексикой, морфологией, разбиением на слова, нормализацией и тому подобными вещами;
  • базы "семантического зеркала" (о ней мы поговорим немножко позже), в которой лежат так называемые термины. Хотя следует заметить, что термины – это не просто слова. Это могут быть и фразы, и подвыражения.

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

Движок поддерживает русский, английский, вьетнамский, арабский, украинский, немецкий, французский, испанский языки. Можно добавлять другие языки. База сейчас хорошо (даже очень хорошо!) поддерживает русский и хорошо поддерживает английский, вьетнамский. Сейчас на хороший уровень выходит поддержка арабского языка. Подключение нового языка происходит быстро – в течение месяца база "семантическое зеркало" начинает вразумительно характеризовать тексты.

У нас есть технология рубрикации коротких текстов – например, заголовков, URL (вы не поверите, какими бывают характерными URL!), ключевых слов и тому подобных вещей.

Самая разработанная база на сегодняшний день – русская. В ней больше 400 тысяч терминов. Вторая – английская. Третья – вьетнамская.

Дело в том, что мы сейчас вплотную работаем с Вьетнамом. В частности, наш веб-фильтр "Ремпаро" внедряется у крупнейшего вьетнамского провайдера. Поэтому у нас достаточно разработанная вьетнамская база.

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

Почему почти не используется статистика?

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

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

Постоянно ведется контроль уровня "шума". Это нужно, чтобы избежать ситуации, когда некий термин включает огромное количество рубрик с высокой степенью релевантности. Ведется корректировка весов терминов, когда самые нехарактерные термины имеют больший вес. Маленькие – понятно, что там предельный случай слово "вот", хотя это не термин, и оно могло бы иметь там очень низкий вес, а слово "индустриализация" – очень высокий.

Учет морфологии – очень важный момент. Еще раз повторю, что термин – это не обязательно слово. Иногда мы можем учитывать морфологию. Иногда мы можем использовать основу как термин. Иногда мы можем использовать слово в определенной форме как термин.

База очень быстро накапливается. Собственно, вьетнамская база работала уже через месяц.

Вот перед вами пример рубрикации соответствующих ресурсов. Я специально выбрал два "сексуальных" ресурса. Есть очень существенные различия между набором категорий на каждом из них.

Сайт www.xxx.com имеет предельный, максимальный вес, которого на самом деле почти никогда не бывает (95 по факту максимальный вес). Если мы с высокой, предельной вероятностью определяем, что xxx.com – это порнография, то на примере статьи из "Википедии" мы видим, что это в первую очередь образовательная статья, и никакого отношения к порнографии она на самом деле не имеет. Хотя при любом поиске по ключевым словам (подчеркиваю – при любом поиске по ключевым словам!) она будет приписана к порнографии.

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

Как это устроено технологически?

Мы применяем серверную технологию. Мы не делаем клиентских решений. Это серверная технология фильтрации. У нас есть два варианта продукта. Это продукт "Cluster", предназначенный для очень высоких нагрузок. Собственно, для нагрузок провайдерского класса. Второй продукт называется "Appliance". Это коробочный продукт типа "все в одном", где стоит Linux и наш фильтр. Имеется веб-интерфейс ко всему этому. Ставим шлюз куда-нибудь в организацию, и продукт работает.

Решение имеет систему родительского контроля. Несмотря на то, что решение серверное, уровень управления в родительском контроле практически такой же, как у клиентских решений. Это наша гордость. Пользователь может создавать индивидуальное расписание в рамках недели из политик, предварительно определенных администратором. Например, запрещать своему ребенку играть с 22-х до 14-ти часов каждый день, кроме субботы и воскресенья. Естественно, родитель может просматривать историю того, куда заходит любимое чадо (есть специальные log-файлы), и тому подобные вещи.

Технологически наше решение задействует HTTP-прокси. Понятно, что в HTTPS возможна фильтрация только по IP. Это не имеет прямого отношения к технологии, хотя имеет отношение к продукту. У нас прозрачный HTTP-прокси. В варианте с провайдером это всегда так, естественно. Предполагается, что весь HTTP-трафик тех, кто подписан на услугу, перенаправляется на нас.

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

В качестве основы мы используем Apache Traffic Server. Технологически система представляет собой плагин для Apache Traffic Server, плюс некоторое количество патчей собственно в Apache Traffic Server. Это совершенно великолепный продукт, сверхскоростной и очень хорошо сделанный. Он специально приспособлен для того, чтобы на его основе делать другие продукты. Это почти библиотека в некотором смысле.  Также очень приятно работать с их гео-командой.


Каким образом работает веб-фильтр?

Опять же, "сердцем" фильтра является конечный автомат, машинка-решатель "Solver", который интерпретирует правила, задаваемые на языке его конфигурации (Solver Configuration Language). Очень простой язык, декларативный. Это последовательность последовательно сканируемых правил. Правило состоит из предиката (логического выражения) и действия фильтра относительно того, каким образом преобразовать ответ.

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

Функции, которые определяют реакцию, мы называем конвертерами. Это исторически возникшее название такого рода функций, потому что в общем случае они преобразовывают (англ. convert) ответ, а не запрещают или разрешают что-то. Простейшие примеры действий конвертеров – это "действительно запретить" или "пропустить". Но мы можем выдать предупреждение: "Вы уверены, что хотите получить доступ к этому контенту?" - и пропустить после этого, если был получен ответ "да". Мы можем перенаправить куда-то, выдать произвольный свой ресурс с редиректом.

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

Детекторы – это функции, которые непосредственно участвуют в описании предикатов, правил. Вот, скажем, ContentClass – это самый важный детектор, который работает непосредственно с "семантическим зеркалом". Он позволяет сказать: "Да, в этом документе есть такие-то категории и с вероятностью не менее и не более, чем столько-то процентов".

Демонстрирую набор самых интересных детекторов, хотя и далеко не всех. Детекторы названы так потому, что они обнаруживают (англ. detect) некий аспект запроса или ответа. Аспекты весьма разнообразны. Это могут быть аспекты времени запроса и места, откуда географически пришел запрос (у нас есть хорошая база Geo IP). Еще один аспект - это попадание URL в некий список. Мы не пользуемся только "черными" и "белыми" списками. Мы можем создавать произвольное количество списков URL.

Конечно же, есть детектор ContentType, который позволяет определить категории "семантического зеркала", связанные с документом, или даже соотношение этих категорий. Это бывает очень часто важно. Если у нас "секс" сработал с низкой релевантностью, а "образование" – с высокой, ясно, что это образовательный ресурс, а не порнография.

Вот самые распространенные (хотя и не все) варианты действий, которые мы можем предпринимать в этом случае. Запретить, пропустить, выдать произвольный ресурс, предупредить. Про политики расскажу немного позже.

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

Поскольку предикаты – это логические выражения, работающие по логике короткого замыкания, очень часто предикат оказывается вычислен значительно раньше конца запроса. Если складывается такая ситуация, что мы уже вычислили достаточно для того, чтобы принимать решение – мы его принимаем. Логика, поверьте мне на слово, там оптимальная. Теоретически оптимальная в этом смысле.

 

"Движок" нашего "семантического зеркала"в урезанном виде применяется для работы с ключевыми словами. Помимо того, что мы используем категоризацию и списки URL, мы позволяем пользователю задавать свои ключевые слова. Но только тоже довольно "продвинутым" способом. Используется лингвистический движок "семантического зеркала".

Все слова, которые задает пользователь, являются тем, что мы называем "характеристическими терминами". При срабатывании они однозначно говорят о том, что эта категория в документе присутствует. Не с некоторым уровнем релевантности, а с вероятностью в 100 %.

В частности, очень здорово, что движок "семантического зеркала" позволяет учитывать язык. Это очень важно, потому что одинаково написанные слова в разных языках могут означать разные вещи. Язык мы умеем определять автоматически. Мы умеем работать, в том числе, и с двуязычными документами. Умеем автоматически определять два языка в документе.

Могу привести пример. В немецком слово "mist" означает "навоз".

Наш "Solver" позволяет задавать политики. Политика - это просто именованный набор правил с критерием применимости. Критерий применимости – это фактически просто предикат (опять же, с точки зрения модели пользователя, который пользуется политикой), который соединяется операцией "и" с тем предикатом, который добавляется, когда человек пишет в тексте вызов политики.

Кроме того, политика может быть помечена как доступная не только автору правил, но и пользователю. В этом случае политика может использоваться, как я уже упоминал, в настройках родительского контроля в расписаниях. Например, у нас существует политика "no games", которая запрещает игры.

Система обладает высокой производительностью и масштабируемостью. Фильтр прекрасно работает на многоядерных системах. Все это результаты реальных тяжелых нагрузочных тестов. Мы можем "прокачать" гигабит в секунду при 10 тысячах транзакций в секунду, в общем, на не очень "страшном" по современным представлениям сервере.

Максимум, который мы на сегодняшний день можем вместить в одну очень мощную машину, это примерно 5 гигабит в секунду. Но для этого нужно последнее поколение Zion. Два Zion последнего поколения.

Система, естественно, поддерживает веб-интерфейс конфигурации для коробочного продукта "Appliance". Это понятно и достаточно тривиально. В случае с продуктом "Cluster" примерняется распределенная и транзакционная система. Во-первых, вы можете конфигурировать весь "Cluster" на любом сервере, который помечен как возможный для измерения параметров конфигурации. Во-вторых, самое важное – если конфигурации "Cluster" не нравятся, то система автоматически вернется к использованию предыдущей версии. Конфигурация либо принимается целиком, либо не принимается вовсе.

Собственно, все. Теперь можно задавать вопросы.

Вопросы и Ответы

Реплика из зала: Здравствуйте. Вы на стадии производства же уже это используете, правильно?

Яков Маркович: Мы сейчас проводим тестирование на продакшене у провайдера во Вьетнаме.

Реплика из зала: Какое наибольшее количество запросов в секунду вам удалось поддерживать?

Яков Маркович: Вы знаете, пока объем не очень большой.  Первоначальное тестирование – всего 20 тысяч пользователей. Поэтому в районе 30-ти тысяч в секунду.

Реплика из зала: Понял. Спасибо.

Реплика из зала: Здравствуйте. Хотелось бы уточнить. У вас есть мультиязыковая система с ключевыми словами. Как вы решаете проблему омонимов? Если, например, взять два языка – русский и английский, то у вас уже зигзагообразная омонимичность будет.

Яков Маркович: Если вы не против, на этот вопрос ответит Михаил Волович, наш главный лингвист.

Реплика из зала: С удовольствием. Мы просто столкнулись с теми же самыми проблемами в своих системах.

Михаил Волович: Русско-английский: русский – кириллический, английский – латиница?

Реплика из зала: Да. Примерно. Именно написано… Взять, например, слово "tank". Это "танк" и "бензобак".

Михаил Волович: Вообще говоря, мы пока не работали с translate.

Реплика из зала: Это не translate. Это именно английское слово "tank". Если мы пытаемся перевести… Допустим, у нас есть мультиязычный текст. Вы пытаетесь найти категорию этого текста, но за счет омонимов…

Михаил Волович: Ответ, видимо, очень простой. У нас довольно мало терминов однословных вообще. А если берется больше контекста – эта проблема решается сама собой.

Реплика из зала: Если взять, например, контекст "tank" (english) и "vehicle", то это однозначно "бензобак", потому что в Англии значения "танк", скорее всего, не будет. А если "tank" (english) "serial", то это значит "танк". Именно категоризация с применением перевода слова. Понять точно, что имелось в виду.

Михаил Волович:Нет, просто слово "tank" не будет признано пригодным для установления в качестве термина именно в силу многозначности. Будут взяты какие-то сочетания вроде тех, которые вы назвали, которые уже будут срабатывать.

Реплика из зала: Понятно. А как выглядит сама база данных терминов, кто ее конкретно поддерживает? Это, я так понимаю, экспертная оценка какая-то, которую дают лингвисты?

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

Реплика из зала: А выглядит она как – плоско или…

Михаил Волович: Она выглядит довольно смешно – в виде набора файлов в "Word". Редактируется прямо в "Word". Потом собирается XML, из которого уже собирается база, собирается macro XML.

Реплика из зала: Она древовидная или иерархическая? Как вы делаете категоризацию этих слов?

Михаил Волович: Есть у нас рубрика. У нее есть подчиненная рубрика. И у этой рубрики подчиненная есть.

Реплика из зала: Эта древовидная структура – насколько я знаю, это патентованная технология "Гет Имаджес". Есть такая система продажи картинок, которая очень сильно анализирует свои изображения за счет как раз категоризации ключевых слов.

Еще один вопрос. Насколько у вас большая база данных? Когда вы составляли правила для фильтрации, у вас там задавались категории. Реально, чтобы хорошо отфильтровать трафик, вам нужно знать все содержимое базы данных, чтобы правильно составить эти фильтры. Если она у вас там состоит хотя бы из 20-ти тысяч категорий, то сделать это сразу нереально.

Михаил Волович: Нет. Там порядка трех тысяч категорий. Из них реально в правилах учитывается только часть. Есть категории – например, нефтепереработка. Для фильтра она очевидным образом бесполезна.

Реплика из зала: Понятно. Вы сейчас это используете только для фильтрации? Как раз вопрос автоматического перевода. Если вы знаете контекст текста, то автоматический перевод будет максимально релевантен. Это очень... Технология прорывная, на самом деле. Если вы говорите, например, что данный текст принадлежит к описанию каких-то военных действий, то слово "tank вы однозначно переводите как "танк". Это очень круто, на самом деле.

Михаил Волович: Много чего можно использовать там хитрого. На самом деле, эта простая вещь работает довольно неплохо. Несмотря на то, что термины подбираются, как бы, руками, все равно оказывается, что подавляющее большинство текстов весьма уверенно рубрицируется. В большинстве случаев для тех, которые почему-то проскакивают, удается подобрать термины из них, которые решают проблему с ними и при этом полезны для других текстов тоже.

Реплика из зала: Спасибо.

Реплика из зала: У меня вопрос. Легко ли ваша система адаптируется к анализу такой нетривиальной информации, как, например, критика власти или пропаганда деструктивных сект? Это первый вопрос. А второй вопрос я задам после того, как вы на первый ответите.

Михаил Волович: Да, к сожалению, в некотором смысле она адаптируется к этому очень легко. Мы сейчас нашим вьетнамцам морочим голову. Говорим, что это страшно трудно. Что мы хорошо умеем распознавать политику, но очень плохо – критику власти. На самом деле, это полная чепуха, потому что, конечно, все это очень легко распознается. Просто какой-нибудь пресловутый "Путин" – вполне достаточно для того, что здесь критикуется власть.

Реплика из зала: Просто власть можно критиковать в комбинации с вознесением какого-то другого (партии, например). Это может перемежаться. Вы можете, наоборот, в пропаганде "Единой России" (которую большинство не любят) найти, наоборот, антипропаганду. Поэтому я сказал, это нетривиальный же анализ политики. Секс – это понятно. Эротика – там все просто.

Михаил Волович: Очень похожие технологии используются в системе "Крибрум", которая как раз "вытаскивает" оценки. Да, в принципе, мы умеем это делать. Если сильно надо, то это делается достаточно хорошо. Отчасти вот этими средствами, которые просто фиксируют наличие отрицательно окрашенных высказываний о власти (например, вьетнамской).

Реплика из зала: Для Вьетнама вы именно такое направление прорабатываете?

Михаил Волович: Нет-нет. Для Вьетнама от нас этого очень хотят, но мы пока отбиваемся.

Яков Маркович: Более того. Провайдеру это совершенно не нужно. Провайдеру нужно зарабатывать деньги. А там очень большим спросом пользуется родительский контроль в связи с культурной напряженностью. Конфуцианская мораль вступает в очень большое противоречие с нашим дорогим Интернетом, и родителям очень тяжело. За это просто платят деньги. В смысле, не государство платит деньги, а родители.

Реплика из зала: Я понял. Извините, я еще один вопрос задам. Как вы двигаетесь в сторону внедрения вашего решения на федеральном уровне для того, чтобы именно оградить наше общество от нежелательного контента? 

Яков Маркович: Почему я?

Михаил Волович: Я никак не двигаюсь. А вот вы как-то…

Яков Маркович: Прошу прощения. На самом деле, я тоже, потому что я – главный разработчик проекта.

Реплика из зала: У меня два вопроса. Один – первый, а второй – как вы ответите. Определились ли вы с ценой вашего продукта?

Яков Маркович: Дело в том, что этот продукт продается… Еще раз. Коммерческая версия, которая есть сейчас, – это версия для провайдера. Штучная и очень большая. Вы про это спрашиваете или про цену для конечных пользователей?

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

Яков Маркович: Вот Алекс Тутубалин, он – партнер ("Ашманов и партнеры"). Вот он пусть и отвечает.

Алексей Тутубалин: Но с ценой же все понятно. Вещи, за которые люди согласны платить – это цена, близкая к цене антивируса. Где-то, может быть, 30 долларов в год, где-то, может, 5. Бывают бесплатные антивирусы. Это мы всё знаем. Это первый спрос – от родителей. Я сам многодетный отец – у меня спроса пока нет, но, наверное, скоро будет.

Есть другая вещь. Когда издержки целиком ложатся на провайдера. Требование, чтобы у него в сети не было экстремизма или еще какой-нибудь гадости. Во Вьетнаме (я, на самом деле, этим проектом не занимаюсь) есть законодательное требование об ограничении доступа к играм. Что-то такое там было.

В принципе, такие требования со стороны закона могут быть – не допустить того, сего. Это чистые издержки провайдера. Он на пользователя, конечно, перекладывает их в тарифах, но в счете у пользователя этой строчки нет. За что платит пользователь? За строительство сети, смену дежурного в дата-центре. За вот это, вот это и вот это он платит, и за обеспечение соблюдение законов тоже. Цена, на самом деле, конечно, копеечная. 11 долларов в месяц  - такая будет цена для пользователя, не больше. Больше не бывает.

Может быть, во Вьетнаме цена будет меньше.

Реплика из зала: Немного не понял: у вас есть коробочный продукт для семьи?

Яков Маркович: Нет, мы не продаем "коробку".

Реплика из зала: Нет, вы доклад делали с упоминанием коробочного продукта, по идее, то есть сервиса.

Яков Маркович: Простите, нет.

Реплика из зала: Сервис, который вы представили – это именно "коробочный", то есть узконаправленный.

Яков Маркович: Секундочку. Под коробочным продуктом вы имеете в виду "коробку", которую продает, например, "Мегафон". Я просто под коробочным продуктом понимаю несколько другое. Нет, это не коробочный продукт. Это услуга, которая стоит денег. Во Вьетнаме это что-то типа 15-ти долларов в год, вот такого порядка.

Реплика из зала: Вы будете продавать эту слугу через провайдеров, я правильно понимаю?

Яков Маркович: У нас ее провайдер и заказал.

Реплика из зала: Нет, я имею в виду, схему для конечного пользователя, потребителя "порнушки" и потребителя "Смешариков".

Яков Маркович: Текущая коммерческая разработка, то, что сейчас непосредственно продается, то, что о чем сейчас мы договорились, за что нам платят деньги – это продукт для провайдера, который уже сам со своих пользователей берет деньги за эту услугу. Или не берет, а нам платит.

Реплика из зала: Интересно. Ничего не понятно. Спасибо вам.

Михаил Волович: Это серверное решение, в любом случае. Может быть, продукт "Appliance" для интернет-кафе или корпоративной сети. Но не "коробка" для винды конкретного человека.

Реплика из зала: Отлично. Давайте теперь с этих позиций. Я – владелец кафе. Почем? Владельцев кафе, на самом деле, в Москве, Петербурге, Ебурге – там конечное число пользователей. Они готовы по каким-то…

Яков Маркович: Это правда. Вы обратили внимание, что я рассказывал про вьетнамский проект? 

Реплика из зала: Да. Но там очень много… Я обратил внимание на фильтрацию, например, для детворы.

Яков Маркович: Я могу вам сказать – я знаю. Единственное…

Алексей Тутубалин: Заходите на сайт – www.ashmanov.com. У нас есть служба продаж, честное слово. Продадим. А про цену вам там все расскажут.

Реплика из зала: Мне интересно, на самом деле, чтобы вы мне продали так же, как потом продадите Иванову. Если Иванову продадите дешевле, потому что я первый пришел на рынок, и я дорогой, обидно будет...

Алексей Тутубалин: Это проблема. У первых покупателей всегда такая проблема.

Реплика из зала: Понятно. Вы не определились еще с этим?

Алексей Тутубалин: По факту, с кафе – нет. Думаю, что реально речь о нескольких месяцах в лучшем случае. Пока клиент этого продукта – это крупный провайдер вроде "Мегафона" или "Билайна" и так далее.

Реплика из зала: Вот теперь понятно. Все, ясность есть.

Реплика из зала: Здравствуйте. Есть вопрос. У вас происходит фильтрация постранично или подоменно, например?

Яков Маркович: Постранично.

Реплика из зала: Вы говорили, что у вас не используется никакая статистика, статистические данные не копятся.

Яков Маркович: Про статистику говорилось в контексте определения тематики текста. Статистические методы в применении к определению тематики текста.

Реплика из зала: Внутри одного домена могут быть плохие и хорошие странички, например.

Яков Маркович: Конечно. Мы не фильтруем домен. Мы фильтруем непосредственно здесь и сейчас.

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

Яков Маркович: Да. Я его прекрасно знаю. Был.

Реплика из зала: Были хорошие запросы, вроде бы обычные (например, "мокрые киски"). Он потом был заблокирован полностью.

Яков Маркович: Да. Я знаю.

Реплика из зала: Как у вас будет дело обстоять с такими запросами, если вы не смотрите, что – да, сайт, плохой целиком?

Яков Маркович: А мы смотрим не на вопрос, а на ответ. Прошу прощения.

Реплика из зала: Это может быть одна страничка. Это блок пользователя.

Яков Маркович: И что? Эта страница будет заблокирована.

Реплика из зала: Вы будете блокировать по этим двум словам в результате?

Яков Маркович: Нет. По этим двум словам мы блокировать не будем. Мы будем блокировать по содержимому ответа. Этот ответ не дойдет. Вот и все.

Реплика из зала: Нет, не так. Есть, например, сайт кошководов.

Яков Маркович: Хорошо.

Реплика из зала: И там есть…

Яков Маркович: Простите. Блокировка… Вот, у вас идет HTTP-запрос. Вы себе представляете, как это происходит?

Реплика из зала: Вот, у меня есть конкретный вопрос. Можно? Есть сайт про кошек, там есть одна страничка. Там фотография с подписью, и ничего больше нет. Вы можете определить, что это за картинка, только по окружению домена. Есть другой сайт, где блог какого-нибудь плохого человека, и там тоже одна картинка, и одна подпись. Несмотря на домен и то, что вокруг, получается, вы определить не сможете?

Яков Маркович: Нет, простите, еще раз. Мы не блокируем домены. Вернее, блокируем. Домены "xxx", как правило, находятся…

Реплика из зала: В одном случае вы можете заблокировать страницу, а в другом – лучше бы ее показать.

Яков Маркович: Почему? Еще раз. Если на этой странице нет плохого контента, на этой и только этой странице.

Реплика из зала: Как узнать?

Реплика из зала: Имеется в виду, одна страница – с порно, где "мокрые киски" подпись (одна фотография), а другая страница – с кошками, где тоже "мокрые киски".

Реплика из зала: Как узнать – показать или нет?

Яков Маркович: Минуточку. Понятно, что не "серебряная пуля", в том смысле, что, вот, мы думаем, пытаться нам распознавать картинки или нет. Но вы, на самом деле, не поверите. Дело в том, что в страницах, в которых вроде бы совсем нет текста – текста "до чертиков". Дело в том, что ресурсы такого порядка хотят, чтобы их нашли.

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

Реплика из зала: Но если эти сайты себя как-то продвигают… Обычно, если это фотогалерея (если без AJAX, без всего) – это будет отдельная страничка только с фотографией. Так обычно делают. Получается, что вы эту страничку пропустите. Но если вы посмотрите, что все соседние странички на этом домене очень плохие, то лучше заблокировать весь домен.

Яков Маркович: Да, совершенно справедливо. Мы сейчас вводим частичный оффлайновый анализ. То, что я рассказывал – это полностью онлайн-анализ. А это частичный оффлайновый анализ, потому что он требует накопления статистики.

Реплика из зала: Это будет какая-то комбинация, и этот фильтр уже будет все-таки основываться на статистике?

Яков Маркович: Это правда. На самом деле, есть масса вариантов. Можно смотреть ссылки со страниц, куда идут, и так далее. Кстати, еще раз. Интересный факт. Иногда анализ текста URL помогает очень много понять.

Реплика из зала: Спасибо.

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

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

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

Михаил Волович: Нет. Поисковик не найдет. Просто найдутся конкуренты, у которых это слово будет представлено гораздо более ярко (например, в заголовке).

Реплика из зала: У меня уточняющий немножко вопрос. У вас был слайд с цифрами, какой конфигурации сервера соответствует количество запросов. Я немножко не понял. Насколько крупного провайдера вы можете потянуть?

Яков Маркович: Очень важный момент. Вы же понимаете, что, например, трафик торрента через нас не идет. Это важно. Мы можем стойкой из восьми очень мощных машин (потому что, понятно – часто важнее количество в стойке, а не мощность) "окормить" 40 гигабит в секунду. Машины такого порядка, 64 гига последний "Zion" с галстоуновским ядром – два по шесть. Имея восемь машин такого порядка, мы в состоянии "окормить" 40 гигабит в секунду. Дело с том, что мы масштабируемся почти неограниченно. Дальше вы считайте просто.

Реплика из зала: Это не в реал-тайме, это при индексации какой-то? 

Яков Маркович: Мы не индексируем. Мы непрерывно анализируем.

Реплика из зала: Ясно. Спасибо.

Реплика из зала: Здравствуйте. У меня вопрос, наверное, по большей части математики. Я видел у вас красивый слайд с цифрами релевантности. Интересно, как происходит дальнейшее вычисление? Вот, лингвисты сделали словарь, разметочку, все красиво…

Михаил Волович: Очень просто, вот, совсем просто. Эти цифры условные, они не настоящие. Это приведение по некой сложной формуле к процентам. 95, как бы, процентов. Реально машинка работает так. Есть исходный вес термина по умолчанию 10, можно… Есть повышение на две ступеньки – 16, 24, и понижение – 5 и 2. Эти веса домножаются на какие-то коэффициенты в зависимости от количества вхождений термина в текст, длины текста и тому подобное (если они сработали). Получается какие-то цифры. Дальше эти цифры просто по всем терминам суммируются, рубрики, и получается некая цифра. Например, 164. Порог – 40. Все.

Реплика из зала: Фактически ваш словарь – это просто хэш-категория и список ключевых слов или что-то посложнее – есть какие-то семантики между…

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

Реплика из зала: Спасибо.

Реплика из зала: Скажите, пожалуйста. Какая требуется квалификация, чтобы эти словари составлять? Это высшее образование, специально обученные люди – кто это?

Михаил Волович: Я не помню, как это называется. Есть такой принцип. Если одно и то же дело поручить двум одинаково несведущим в нем людям, и один из них – математик, то математик это сделает лучше. Вот, мы примерно из этих соображений берем на работу лингвистов. ОСиПЛ или РГГУ. Иногда других лингвистов. Они это умеют делать. Как-то они быстро этому обучаются. Точнее, так. Некоторые как-то не очень хорошо обучаются, но они у нас уже не работают. А кто-то умеет это делать очень хорошо.

Реплика из зала: Спасибо.

Михаил Волович: Такой просто навык.

Реплика из зала: А что вы делаете с динамическими страничками?

Яков Маркович: Прошу прощения. Что именно вы имеете в виду под динамическими страницами? Это странички, на которых JavaScript много, или как?

Реплика из зала: Да, которые AJAX'ом загружают данный текст.

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

Опять же, в практическом применении, случаи, когда мы плохо работаем, редки. Это можно решить. Но затраты на установку в пищевую цепочку вот этого всего хозяйства, скажем, "PhantomJS" (вы знаете, возможно, что это такое – это "безголовый браузер"), слишком велики. Поэтому мы идем на компромисс. Производительность… Иначе это будет неприменимо.

Реплика из зала: Злоумышленник может совершенно посторонний текст загрузить и (неразборчиво, 141:22)?

Яков Маркович: Бороться с нами можно, это я говорю сразу. Но сложно.

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

Михаил Волович: Они предварительно отбираются.

Реплика из зала: TF-IDF стандартная, всем известная. Потом вы, грубо говоря, для каждой рубрики и для каждого слова сопоставляете некоторый вес этого термина в рамках данной рубрики. Правильно?

Михаил Волович: Да. Примерно так.

Реплика из зала: А потом вы просто сканируете текст, и, грубо говоря, получаете в итоге какую-то суммарную величину, которая…

Михаил Волович: Да, да. Все так просто.

Реплика из зала: …либо входит в данную рубрику по порогу…

Михаил Волович: Да. Есть некий порог.

Реплика из зала: Окей. Тогда вопрос. "Семантическое зеркало". Используете ли вы действительно какие-то именно семантические технологии в плане анализа текста, может быть, на этапах морфологии или еще что-нибудь? Интересно мне, я заканчивал специальность "Искусственный интеллект", поэтому так прицепился.

Михаил Волович: Честно – слово "семантический" здесь для красоты. (Смех).

Реплика из зала: Это банальная математика и все-таки задействованы статистические методы?

Михаил Волович: "Семантический" – потому, что человек про это подумал и некоторый отбор произвел. Но, вообще говоря, это такой очень простой словарь, в который занесены характерные слова. Отобранные, в конечном счете, вручную.

Откуда они берутся… Изначальные претенденты могут браться разными способами, но ручная фильтрация этого есть. Плюс мы там тестируем и смотрим, чтобы база не "шумела".

Реплика из зала: Ясно.

Михаил Волович: А "зеркало" – оно, кстати, тоже для красоты.

Реплика из зала: Используете ли вы стемминг на этапе морфологического анализа, и если да, то с помощью каких инструментов?

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

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

Реплика из зала: Я не уверен, что смогу правильно сформулировать, потому что не совсем по теме. Ребята здесь предложили альтернативное использование этой технологии, в частности, переводы. Определяем тематику текста и четко переводим. Я бы еще предложил, может быть, тематический поиск по произвольным текстам (сюда же вполне можно отнести себя).

Вопрос как-то вот так я хочу сформулировать. Отторгаема ли у вас технология вот этого "семантического зеркала", то есть можно ли ее попользовать отдельно?

Михаил Волович: Можно.

Реплика из зала: Я понял, что это отдельно надо общаться.

Михаил Волович: Можно обращаться в компанию "Ашманов и партнеры". Это вполне обсуждаемо.

Реплика из зала: Я так понимаю, что сейчас у базы есть ценность, основная в том, что она наполнена… Собственно, словарь составлен и категоризирован для каталогизации.

Вопрос второй. Если нужен каталог более тематический (узкая тематика какая-нибудь, профессиональная сфера), и там надо организовать поиск. Примеры привести, с которыми я сталкивался – бухгалтерия и налогообложение (законодательство). Там свой каталогизатор, тоже что-то необходимо делать. Насколько эту технологию с вашей точки зрения повторить просто?

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

Реплика из зала: Хорошо, спасибо.

Реплика из зала: Вопрос по поводу операций с терминами, явно вы осуществляете какие-то проверки и прогонки данной категории на массиве текстов. Каким образом вы потом корректируете эти веса, основываясь на чем? Есть два слова. Для какого вы выбираете, что нужно больше веса, а вот для этого меньше – чем вообще руководствуетесь в таких случаях? Или нет у вас как такового понятия обучения системы?

Михаил Волович: Машинного обучения нет. Есть человеческое обучение. Просто смотрим, какие термины, что сработало, что не сработало. Что сработало там, где не должно было сработать. Обычно это априори понятно. Но иногда бывают какие-то ошибки. Они корректируются.

Реплика из зала: Полностью вручную?

Михаил Волович: Да. Полностью вручную. На самом деле, кажется, что это очень трудоемкая вещь. На самом деле, она довольно быстро делается. У нас этим занимается, в общем, даже не так много народу. Вьетнамскую базу сейчас активно наполняют четыре человека. Но они "полставочники" и студенты при этом. И базу уже наполовину наполнили.

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

Реплика из зала: Кстати, не планируете использовать вашу систему в системах машинного перевода?

Михаил Волович: Понятно, если мы будем делать в очередной раз… Последний раз систему машинного перевода делали году в 1999-м. Если нелегкая нас занесет в то, чтобы еще раз "в эту реку вступить" – конечно, мы будем использовать все, что сможем.

Реплика из зала: Понятно. Спасибо.

Михаил Волович: В нашем вьетнамском поиске собираемся использовать. Еще не используем, но сейчас будем. Уже отрубрицировали. Там сейчас думаем, как это применять.

Реплика из зала: Можно еще один вопрос? По вьетнамскому языку. Скажите. Надо быть носителем языка, или достаточно образования?

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

Реплика из зала: Во Вьетнаме есть лингвисты?

Михаил Волович: Да.

Яков Маркович: Еще какие.

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

Реплика из зала: Интеллигенция, наверное? 

Михаил Волович: Да. Плюс еще там с диалектами проблемы. В общем, как-то плохо получилось. А "правильные" вьетнамцы – да, они умеют все делать хорошо, не хуже наших. 

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Евгений Чигиринский

Евгений Чигиринский

Руководитель команды разработчиков Microsoft.

Евгений Чигиринский (Microsoft) рассказывает о процессах разработки в Microsoft и отвечает на вопросы о принципах работы одной из крупнейших в мире ИТ-компаний.

Сэнди Гупта (Sandy Gupta)

Сэнди Гупта (Sandy Gupta)

Главный руководитель Open Solutions Group (OSG) в Microsoft.

Сэнди Гупта (Microsoft) расскажет о стратегии Microsoft по упрощению разработки "облаков" и по созданию возможностей для ПО с открытым исходным кодом.

Альваро Видела (Alvaro Videla)

Альваро Видела (Alvaro Videla)

Разработчик ПО в Cloud Foundry at VMware в Швейцарии.

Альваро Видела (Liip AG) сделал доклад о масштабировании с помощью RabbitMQ.