diploma-3 (1015783), страница 7
Текст из файла (страница 7)
Наличие асинхронных операций записи при вычисления подсчетов в данномслучае является огромным преимуществом, Мы используем параллельныйдоступ к базе данных. Это особенно оказывается критично на синхронныхоперациях чтения.Для параллельного доступа к базе данных, и исключения блокировок мыиспользуем пул соединений с базой данных. Ниже на рисунке представленодерево контроля потоков пула соединения.Рис. 1.12.
Дерево контроля для пула соединения.491.5.4. АРИФМЕТИКА С ФИКСИРОВАННОЙ ЗАПЯТОЙВ результате деления при осуществлении сбора подсчетов используетсявещественное деление. Для инкремента подсчетов удобно использовать атомарную операцию hincrby. Однако, она работает только с целыми числами.В этом случае мы предлагаем следующий подход.В качестве вероятности, мы будем использовать числа с фиксированной запятой по основанию 576460752303423488 (259 ).
Такое число выбраноне случайно, это максимальное положительное число используемое в erlang,которое может поместиться в машинное слово 64-битной архитектуре.Base := 576460752303423488;⌊⌋Baseadiv(X, Y ) →·X .Y⌊⌋Xamul(X, Y ) →·Y .BaseПри таком подходе возможно появления ошибок гораздо большего порядка, чем существующее машинное «эпсилон», но они все равно будут пренебрежимо малы. Для скорости вычислений и экономии памяти, важно соблюсти последовательность вычислений.По проведенном тестам прирост скорости составил примерно 14 разпри применении операции hincrby c числами с фиксированной запятой,по сравнению с последовательными считывании и записью в базу данных.1.5.5. ОБУЧЕНИЕ СИСТЕМЫОсновой системы являются базовые алгоритмы моделей IBM 1 и IBM 2(можно найти в приложении). Причем с точки зрения эффективности авторотдает предпочтении IBM 1.
При использовании IBM 2 при падении производительности улучшения качества работы системы не замечено было.В большинстве случаев для полной сходимости было достаточно около10 итераций. Потому в рабочей системе предлагается условие сходимостизаменить проверкой значения счетчика цикла.50ИНИЦИАЛИЗАЦИЯВ базовом алгоритме указано, что необходимо перед началом его работыинициализировать величины t(ωe |ωr ) для всех ωe и ωr в параллельном корпусе. Логично было бы для этого использовать абсолютную частоту словав каждом подкорпусе.
Однако, для этого необходимо прочитать весь корпусцеликом. Если внимательно посмотреть на базовый алгоритм, то становится ясно, что от начального значения величин t(ωe |ωr ) ничего не зависит, если они все одинаковы. В таком случае, можно их инициализировать заранеекакой-либо константой, например в данной работе используется константаравная 0.5.ВОЗМОЖНЫЕ ОШИБКИОчень важным моментом реализации алгоритма обучения является то,что оценка вероятности модели и вычисления подсчетов должны происходить сразу по всему корпусу текстов.На начальных этапах реализации системы нами была допущено серьезная ошибка. Приложения читателя, проходила по корпусу и считывало 1000строк. После этого эта тысяча строк отправлялась на обработки и по ней строилась модель перевода.
Затем считывалась следующая порция строк.В результате этих действий подсчеты вычислялись только для локальногонабора строк, и затем по ним вычислялась вероятность переводных соответствий и перезаписывала вероятность вычисленную ранее.После окончания работы алгоритма обучения мы получали вероятностипереводных соответствий обученные только на последней тысяче строк, снекоторым влиянием остального корпуса.Установить ошибку удалось только после запуска алгоритма в предельном случае на корпусе состоящим из двух строк, при проходе полного алгоритма обучения на каждой из них.511.5.6. РЕАЛИЗАЦИЯ ИНТЕРФЕЙСОВ ДЕКОДЕРАРассматриваемая система обладает тремя видами интерфейса:• консольные;• простой веб-интерфейс;• rest-интерфейс.Консольное приложение является стандартным отладочным интерфейсом ОТП приложений.
Для перевода достаточно просто вызывать соответствующую функцию модуля.Веб-интерфейс декодера выполнен в виде отдельного ОТП приложенияи представляет из себя полноценный веб-ресурс, реализованный с помощьюбиблиотеки mochiweb.Мы не будем в работе приводить как внешне выглядит клиентская частьВеб-приложения, которая отображается в браузере, так как она представляет собой всего лишь текстовый элемент ввода, две кнопки («перевести» и«улучшить перевод»), и текстовый элемент вывода.Важнейшей частью Веб-приложения является XSLT-преобразователь. Вданном случае он был написан на С c использованием libxml2 и libxslt.
Изerlang он вызывается как порт-сервер. На вход подается строка XML которая содержит в себе данные (в нашем случае, это перевод исходного текста вслучае ответа на запрос) и шаблон XSL, в котором описано как данные передавать. Для увеличения быстродействия XSLT преобразователь (на сторонекода на C) использует хэш-таблицу, в которой записываются использованные ранее XSL шаблоны. Сделано для того, чтобы не загружать при повтором обращении каждый шаблон снова. В рамках проекта было реализованодве версии преобразователя c запоминанием шаблонов и без него.
Версия безхэш-таблицы работает медленнее, но удобнее при «горячей замене» шаблонауже на работающем коде. Кроме того, преобразователь является не блокирующим и при одновременных обращениях вызывается параллельно. Последнее дает прирост производительности при наличие нескольких процессоровили ядер.52Rest-интерфейс декодера также выполнен в виде отдельного ОТП приложения и представляет из себя полноценный веб-ресурс реализованный с помощью библиотеки mochiweb.После поступления POST запроса приложению, оно начинает передаватьтекстовый (Content-Type: text/plain) HTTP (chunked) поток с наиболее вероятными вариантами перевода.
Этот поток будет передаваться до тех пор, покаклиент не закроет соединение, или не будут перебраны все варианты улучшения перевода.Поток представляет из себя набор чанков в рамках спецификации протокола HTTP 1.1. Каждый чанк содержит количество передаваемых байт ипоследовательность передаваемых данных.Каждая строка полного перевода исходного текста передается в отдельном чанке и обязательно заканчивается символом перевода строки.В отличие от web-интерфейса в этом случае клиенту не нужно будет самому запрашивать улучшение перевода. Самый первый «жадный» вариантперевода передается в первом чанке потока.531.6.
ТЕСТИРОВАНИЕ РАЗРАБОТАННОЙССМП1.6.1. ОЦЕНКА КАЧЕСТВА ПЕРЕВОДАДля оценки качества перевода достаточно взглянуть на таблицу ниже. Вней приведены переводы одного и того же фрагмента для различных статистических систем машинного перевода.Таблица 1.3. Различные переводы исходного текстаИсходный текст adopted at the 81st plenary mee ngПроф. переводчик принята на 81-м пленарном заседанииMoses приняли на 81 полный встречиGoogle-переводчик принятой на 81-е пленарное заседаниеДанная система принята без голосования на 81 пленарном заседании в БрюсселеВсе правильно, заседании было в Брюсселе, но в исходном тексте этого не было.
Однако не совсем корректно сравнивать системы, обученные наразных корпусах текстов. Потому мы будем использовать систему машинного перевода основанную на пакете Moses (декодировщик Moses и обучающаясистема GIZA++), обученную на том же самом входном корпусе, что и нашасистема.Для оценки качества перевода существует набор формальных метрик.• BLEU (Bilingual Evaluation Understudy);• METEOR (Metric for Evaluation of Translation with Explicit ORdering);• NIST (названа по имени университета National Institute of Standards andTechnology);• WER (Word error rate).Чаще всего системы машинного перевода оценивают по метрике BLEU:54• высокая корреляция с оценкой человека;• для оценки требуется готовый перевод тестовых предложений, выполненный профессиональным переводчиком.(BLEU = Bp · e{Bp =N∑)Wn log(pn )n=1∑ ∑1,l c > lh ;lhe(1− lc ) , lc 6 lh .иpn =числосреза (ηc )∑ ∑число(ηc )C∈Sc ηc ∈CC∈Sc ηc ∈C• Sc — множество кандидатов на перевод;• C — кандидат на перевод;• ηc — n-грамма кандидата на перевод;• lc — длинна кандидата перевода;• lh — длинна экспертного перевода (выполненного человеком);1• Wn =— вес, для метрик основанных на BLEU, но не эквивалентныхNей, может отличаться для каждого n, например NIST назначает большийвес более редким n-граммам;• N = 4, n-грамность оценки.Таким образом, BLEU есть взвешенное среднее числа совпадений nграмм (слов) кандидата и n-грамм в переводе эксперта.
Метрика являетсяинвариантом порядка n-грамм, важно наличие совпадений [34]. Чем вышезначение метрики BLEU, тем перевод хуже.Метрики NIST и METEOR основаны на BLEU, WER — на вычислениирасстояния Левенштейна.Для оценки перевода системы мы использовали метрику BLEU. Для подсчета метрики было выделено 1024 предложений в качестве примеров экспертного перевода, и 1024 предложений было переведено рассматриваемойсистемой МП. Для этого набора предложений метрика BLEU = 0.243 для55единственной итерации работы декодера, и 0.209 для лучшего варианта из100 полученного в результате нескольких итераций. Система МП, построенная на основе пакета Moses, дает метрику BLEU = 0.209 для модели IBM 3 иBLEU = 0.173 для модели IBM 5.Таблица 1.4.
Оценки перевода текстаСистемаBLEUТекущая (1) 0.243Текущая (100) 0.209Moses (IBM 3) 0.201Moses (IBM 5) 0.173Высокие значения метрики BLEU показывают, что система проявляет себя не в лучшем свете на тестовом корпусе, однако сам корпус весьма отличается отличается от тех для которых создана данная система.Существует целый ряд неформальных способов оценки систем машинного перевода. Чаще всего используют технику «обратного перевода».• исходный отрывок переводят системой c языка L1 на язык L2 ;• полученный отрывок переводят в обраПритную сторону c языка L2 наязык L1 .• сравнивают два варианта отрывка на языке L1 и по их близости судят окачестве перевода.На наш взгляд такой метод оценки не является вполне корректным в случаестатистических систем. Так как согласно уравнению Байеса, в итоге мы оцениваем только модель языка используемой системы. Более того при многократном применении «обратного перевода» к одному и тому же отрывку, снекоторой итерации перевод на L1 и на L2 перестанут меняться.561.6.2.
ОЦЕНКА СКОРОСТИОЦЕНКА СКОРОСТИ ОБУЧЕНИЯНиже мы сравним скорости обучения и работы трех систем машинногоперевода. Для того чтобы показать разницу распределенных (многопоточных) и не распределенных систем эксперименты проводились на разных машинах. Для тестирования рассматриваемой системы было на каждой машинезапускались соответствующие приложения (читатель и обработчик), пропорционально числу ядер процессоров. Тестирование как и ранее проводилосьна смешанном корпусе описанном выше.Высокая скорость текущей (представленной в работе) системы во многом объясняется ее простотой. Однако, для более крупных корпусов текста,скорость обучения может оказаться критичной.Оценка скорости обучения на одном и том же корпусе.Таблица 1.5. Оценка скорости обучения, процессор: Intel Core2 Duo, 1 ядро64 бит, ОП 4Гб, ФС: ext4Система Время, чТекущая (1)≈5Moses (GIZA++)≈ 25Chaski (MGIZA++)≈ 26Таблица 1.6.
Оценка скорости обучения, процессор: Intel Xeon E5506, 8 ядер64 бит, ОП 10Гб, ФС:xfsСистема Время, чТекущая (1)≈1Moses (GIZA++)≈ 22Chaski (MGIZA++)≈357ОЦЕНКА СКОРОСТИ ПЕРЕВОДАСкорость перевода будем оценивать в микросекундах. Причем, скоростьзапуска декодера (Moses стартует в течение минуты на Intel Core2 Duo) ивремя на прочие накладные вычисления учитывать не будем.Таблица 1.7.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
