Первоначально разработанная спецами из IBM, Архитектура управления неструктурированной информацией (UIMA) сейчас обитается в инкубаторе от Apache, являет собой образец открытого ПО и распространяется по апачевой лицензии.
Это — программная инфраструктура, цель которой — анализ больших массивов информации и извлечение из этой информации знаний. Тут мы осторожно остановимся, заглянем в пропасть семантического веба, на дне которой лежит искусственный интеллект, и сделаем осторожный шаг назад.
Apache UIMA хороша тем, что не таит в себе никакой мистики. Всё можно пощупать, поковырять, подпилить.
Она предлагает модульный подход к анализу текста. Например, последовательность анализа может быть такой:
Каждая операция выполняется определённым компонентом, связь между которыми обеспечивается фреймворком (доступны UIMA Java Framework и UIMA C++ Framework).
Таким образом, мы работаем с каналом (pipeline), составленным из компонентов-аннотаторов, каждый из которых выполняет определённую операцию над текстом. На вход подаётся голый текст, на выходе получаем обогащённый xml-файл.
Вот некоторые из существующих аннотаторов:
Принцип работы других компонентов не так очевиден, их список (далеко не полный) можно посмотреть здесь.
При желании можно написать свой собственный аннотатор или собрать канал из уже существующих.
В качестве примера возьмём разбор предложения из статьи «Automate Metadata Extraction for Corporate Search and Mashups» (автор Dan McCreary). Начнём с того, что научим программу понимать, что Sue и Susan – семантически близкие понятия. Рассмотрим два предложения:
Our client is going to sue your company.
This proposal was written by Sue Smith for the Johnson Corporation.
В первую очередь, проводим POS-анализ (part-of-speach, разбор по частям речи). Вот список идентификаторов, обозначающих части речи для английского языка.
На выходе pos-аннотатора получаем:
Памятуя, что искомая Sue имеет идентификатор части речи POS=«np» (грубо говоря, существительное), отметаем первое предложение. Понятно, что традиционный, не семантический поиск, не отличает глагол sue от имени собственного.
Разбираемся со вторым предложением. Воспользовавшись неким словарём (а использование словарей терминов и онтологий − неотъемлемый атрибут семантического поиска), узнаём, что <token POS=«np»>Sue</token> — это сокращённое имя Susan, а два идущих подряд существительных «Sue Smith» − возможно, сотрудник компании за номером 1234747 Susan Smith. Точно так же можем определить, что Johnson Corporation — это организация с идентификатором 347474. Фиксируем полученные знания:
Таким образом, в несколько итераций, мы обогащаем текстовую информацию, чем поднимаем поиск на новый уровень.
Никакой магии.
Что это?
Это — программная инфраструктура, цель которой — анализ больших массивов информации и извлечение из этой информации знаний. Тут мы осторожно остановимся, заглянем в пропасть семантического веба, на дне которой лежит искусственный интеллект, и сделаем осторожный шаг назад.
Apache UIMA хороша тем, что не таит в себе никакой мистики. Всё можно пощупать, поковырять, подпилить.
Она предлагает модульный подход к анализу текста. Например, последовательность анализа может быть такой:
- определяем язык текста;
- находим границы предложений;
- ищем именованные вхождения (имена, названия и т.д.).
Каждая операция выполняется определённым компонентом, связь между которыми обеспечивается фреймворком (доступны UIMA Java Framework и UIMA C++ Framework).
Аннотаторы
Таким образом, мы работаем с каналом (pipeline), составленным из компонентов-аннотаторов, каждый из которых выполняет определённую операцию над текстом. На вход подаётся голый текст, на выходе получаем обогащённый xml-файл.
Вот некоторые из существующих аннотаторов:
- Whitespace Tokenizer Annotator
Простой токенайзер. Используя пробельные символы, разбивает текст на токены: слова, числа, знаки препинания. - Snowball Annotator
Выделяет основы слов. Поддерживает русский язык. Здесь можно почитать, как он работает. - Regular Expression Annotator
Просто-напросто извлекает из текста штуки, которые можно определить, используя регулярные выражения: url, e-mail и т.п.
Принцип работы других компонентов не так очевиден, их список (далеко не полный) можно посмотреть здесь.
При желании можно написать свой собственный аннотатор или собрать канал из уже существующих.
Пример работы
В качестве примера возьмём разбор предложения из статьи «Automate Metadata Extraction for Corporate Search and Mashups» (автор Dan McCreary). Начнём с того, что научим программу понимать, что Sue и Susan – семантически близкие понятия. Рассмотрим два предложения:
Our client is going to sue your company.
This proposal was written by Sue Smith for the Johnson Corporation.
В первую очередь, проводим POS-анализ (part-of-speach, разбор по частям речи). Вот список идентификаторов, обозначающих части речи для английского языка.
На выходе pos-аннотатора получаем:
<AnnotationResult>
<Sentence>Our client is going to sue your company. </Sentence>
<token POS="pp$">Our</token>
<token POS="nn">client</token>
<token POS="bez">is</token>
<token POS="vbg">going</token>
<token POS="to">to</token>
<token POS="vb">sue</token>
<token POS="pp$">your</token>
<token POS="nn">company</token>
<token POS=".">.</token>
<Sentence>This proposal was written by Sue Smith for the Johnson Corporation. </Sentence>
<token POS="dt">This</token>
<token POS="nn">proposal</token>
<token POS="bedz">was</token>
<token POS="vbn">written</token>
<token POS="in">by</token>
<token POS="np">Sue</token>
<token POS="np">Smith</token>
<token POS="in">for</token>
<token POS="at">the</token>
<token POS="np">Johnson</token>
<token POS="nn">Corporation</token>
<token POS=".">.</token>
</AnnotationResult>
Памятуя, что искомая Sue имеет идентификатор части речи POS=«np» (грубо говоря, существительное), отметаем первое предложение. Понятно, что традиционный, не семантический поиск, не отличает глагол sue от имени собственного.
Разбираемся со вторым предложением. Воспользовавшись неким словарём (а использование словарей терминов и онтологий − неотъемлемый атрибут семантического поиска), узнаём, что <token POS=«np»>Sue</token> — это сокращённое имя Susan, а два идущих подряд существительных «Sue Smith» − возможно, сотрудник компании за номером 1234747 Susan Smith. Точно так же можем определить, что Johnson Corporation — это организация с идентификатором 347474. Фиксируем полученные знания:
<AnnotationResult>
<Sentence>This proposal was written by Sue Smith for the Johnson Corporation. </Sentence>
<token POS="dt">This</token>
<token POS="nn">proposal</token>
<token POS="bedz">was</token>
<token POS="vbn">written</token>
<token POS="in">by</token>
<person EmpID="1234747">
<token POS="np">Sue</token>
<token POS="np">Smith</token>
</person>
<token POS="in">for</token>
<token POS="at">the</token>
<org CompanyID="347474">
<token POS="np">Johnson</token>
<token POS="nn">Corporation</token>
</org>
<token POS=".">.</token>
</AnnotationResult>
Таким образом, в несколько итераций, мы обогащаем текстовую информацию, чем поднимаем поиск на новый уровень.
Никакой магии.